You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@turbine.apache.org by Ian Beatty <be...@physics.umass.edu> on 2002/10/16 20:09:00 UTC
Modular Application Design?
Greetings.
I'm checking out Turbine as a possible base for a major web application I'm
starting to design. I see a lot that I like, but I am concerned about one
aspect. Perhaps readers of this list could help to resolve the question for
me.
It's important that the finished application be easily extensible, in the
sense that someone else could develop a "module" that would add to the
application. A module would get inserted into the website's page hierarchy
at a particular location, supplying an entire new branch. For example, it
might define a directory "http://localhost/myapp/module3/" and all contents
of that directory. Or perhaps it would get inserted into an existing
directory (supplied by the base app or an already-installed module) such as
"http://localhost/myapp/somepart/module5/".
As I understand the Turbine framework, this would require files to be
separately inserted into some or all of the application's
templates/app/screens, templates/app/navigations, and templates/app/layouts
hierarchies. In addition, appropriate class files would have to be inserted
at the right places in the application's WEB-INF/classes hierarchy, and
various configuration and properties files might need altering as well.
What I'd really like is a way to just drop a folder or JAR containing all
the module's classes, templates configuration information and properties
into a directory somewhere, and have the Turbine app recognize it. Perhaps
I'd have to specify in an app-global configuration file where that module's
root should be located in the application's existing hierarchy (as it
appears in URLs). Then installing a module is as simple as drag-and-drop,
and edit one file.
(I realize I'd also need to have any back-end support for the module
installed separately, such as EJBs or DB tables, but I'm not worried about
that part here.)
Is this possible in the Turbine framework? Anybody got any neat ideas?
Thanks,
..Ian
-- --- -- --- -- --- -- --- -- --- -- --- -- --- -- --- -- --- -- --- --
Dr. Ian Beatty beatty@physics.umass.edu
Physics Education Research Group voice: 413.545.9483
Department of Physics fax: 413.545.4884
Univ. of Massachusetts http://umperg.physics.umass.edu/idb/
Amherst, MA 01003-4525 USA
-- --- -- --- -- --- -- --- -- --- -- --- -- --- -- --- -- --- -- --- --
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Modular Application Design?
Posted by Rodney Schneider <ro...@actf.com.au>.
Hi William,
> I myself have peeked in the coupled intake code multiple times using a
> debugger, and I can say I have a fair understanding in how intake works
> internally. However, if I want to make my own extensions and contribute
> something back to Turbine, I am not sure how. I think a much clearer
> direction for Turbine is necessary for people like me to contribute
> something back to an excellent code base. The question is how, when,
> and where.
I have just started a thread on turbine-dev entitled "Turbine community
contributions" and I am currently waiting for everyone to reply. After that,
I will post a message to this list summarising the conclusions. I am
committed to helping maintain the T2 codebase and there are definitely others
who feel the same. I am glad that you are also willing to help.
Thanks,
-- Rodney
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Modular Application Design?
Posted by William Lee <wl...@sendmail.com>.
Scott Eade wrote:
>Good call. I believe that Henning has enhanced the fulcrum intake service
>to support multiple intake.xml files. He has indicated that he is happy to
>provide read-only public cvs access to this code, but he may need a little
>prompting to follow through on this offer.
>
>Cheers,
>
>Scott
>
>
I am still holding off trying to use the fulcrum and the component
mechanism. Previously I heard things about it's going to be deprecated
in future Turbine. It scared me off. Anyway, I feel like Turbine is in
a somewhat in a limbo state right now. The 2.2 release has been
dormant for a long time and there isn't much activity going into the
coupled services. I imagine much of the code is going into fulcrum but
it seems that's is going to change in the future (!). I don't know
when or whether I want to dive my head into the fulcrum world yet.
I've been using the coupled intake extensively with an i18nized app.
From what I see there can be much improvement in that area. Don't get
me wrong, intake is a great thing, but there are several things that can
make it better. For example, the multiple file/module support for
intake would be nice. I would also like to have a more extensible
intake that takes in Collection values (like List) without resorting to
use multiple groups. Sometimes I would just like to get/set a List of
strings, for example, without creating a group for each individual
string, assign the id, and go from there... Also I would like to write
my own validator for a value for things that requires backend server
validation (like validating a hostname), a real RFC 822 parser for email
address, etc. Furthermore, a better error message mechanism is needed.
Right now, I can't really substitute the wrong variable in the error
string very easily using intake. For example, I can't output a message
like "Your input value of X is too large", where X is the value that you
put in. On top of that, I would like to output the error message in a
i18n manner (I'm currently using the i18n tool to do the trick).
I myself have peeked in the coupled intake code multiple times using a
debugger, and I can say I have a fair understanding in how intake works
internally. However, if I want to make my own extensions and contribute
something back to Turbine, I am not sure how. I think a much clearer
direction for Turbine is necessary for people like me to contribute
something back to an excellent code base. The question is how, when,
and where.
Will
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Modular Application Design?
Posted by Scott Eade <se...@backstagetech.com.au>.
Good call. I believe that Henning has enhanced the fulcrum intake service
to support multiple intake.xml files. He has indicated that he is happy to
provide read-only public cvs access to this code, but he may need a little
prompting to follow through on this offer.
Cheers,
Scott
--
Scott Eade
Backstage Technologies Pty. Ltd.
http://www.backstagetech.com.au
> From: William Lee <wl...@sendmail.com>
> Reply-To: "Turbine Users List" <tu...@jakarta.apache.org>
> Date: Wed, 16 Oct 2002 16:33:37 -0700
> To: Turbine Users List <tu...@jakarta.apache.org>
> Subject: Re: Modular Application Design?
>
> Scott Eade wrote:
>
>> I believe what you are suggesting is possible. Classes can be loaded from
>> jar files by default and turbine provides ClasspathResourceLoader for
>> retrieving templates from a jar file. If the classes and templates for a
>> module are provided in a jar file and a configuration file is added to
>> inform the main application about the module (so it knows how to integrate
>> it) then all that should be required is a restart of the webapp to kick the
>> new module off. Note that a new module might also need the resource loader
>> paths and module.packages to be updated in TR.props to work properly.
>>
>> HTH,
>>
>> Scott
>>
>>
> One problem I see with this is with intake.xml and like you said
> TR.props. If a template is using intake for form validation, you
> essentially need to "patch" the file in order for it to work. Is there
> anyway to get around this?
>
> Will
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Modular Application Design?
Posted by William Lee <wl...@sendmail.com>.
Scott Eade wrote:
>I believe what you are suggesting is possible. Classes can be loaded from
>jar files by default and turbine provides ClasspathResourceLoader for
>retrieving templates from a jar file. If the classes and templates for a
>module are provided in a jar file and a configuration file is added to
>inform the main application about the module (so it knows how to integrate
>it) then all that should be required is a restart of the webapp to kick the
>new module off. Note that a new module might also need the resource loader
>paths and module.packages to be updated in TR.props to work properly.
>
>HTH,
>
>Scott
>
>
One problem I see with this is with intake.xml and like you said
TR.props. If a template is using intake for form validation, you
essentially need to "patch" the file in order for it to work. Is there
anyway to get around this?
Will
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Modular Application Design?
Posted by Scott Eade <se...@backstagetech.com.au>.
I believe what you are suggesting is possible. Classes can be loaded from
jar files by default and turbine provides ClasspathResourceLoader for
retrieving templates from a jar file. If the classes and templates for a
module are provided in a jar file and a configuration file is added to
inform the main application about the module (so it knows how to integrate
it) then all that should be required is a restart of the webapp to kick the
new module off. Note that a new module might also need the resource loader
paths and module.packages to be updated in TR.props to work properly.
HTH,
Scott
--
Scott Eade
Backstage Technologies Pty. Ltd.
http://www.backstagetech.com.au
> From: Ian Beatty <be...@physics.umass.edu>
> Reply-To: "Turbine Users List" <tu...@jakarta.apache.org>
> Date: Wed, 16 Oct 2002 14:09:00 -0400
> To: turbine-user@jakarta.apache.org
> Subject: Modular Application Design?
>
> Greetings.
>
> I'm checking out Turbine as a possible base for a major web application I'm
> starting to design. I see a lot that I like, but I am concerned about one
> aspect. Perhaps readers of this list could help to resolve the question for
> me.
>
> It's important that the finished application be easily extensible, in the
> sense that someone else could develop a "module" that would add to the
> application. A module would get inserted into the website's page hierarchy
> at a particular location, supplying an entire new branch. For example, it
> might define a directory "http://localhost/myapp/module3/" and all contents
> of that directory. Or perhaps it would get inserted into an existing
> directory (supplied by the base app or an already-installed module) such as
> "http://localhost/myapp/somepart/module5/".
>
> As I understand the Turbine framework, this would require files to be
> separately inserted into some or all of the application's
> templates/app/screens, templates/app/navigations, and templates/app/layouts
> hierarchies. In addition, appropriate class files would have to be inserted
> at the right places in the application's WEB-INF/classes hierarchy, and
> various configuration and properties files might need altering as well.
>
> What I'd really like is a way to just drop a folder or JAR containing all
> the module's classes, templates configuration information and properties
> into a directory somewhere, and have the Turbine app recognize it. Perhaps
> I'd have to specify in an app-global configuration file where that module's
> root should be located in the application's existing hierarchy (as it
> appears in URLs). Then installing a module is as simple as drag-and-drop,
> and edit one file.
>
> (I realize I'd also need to have any back-end support for the module
> installed separately, such as EJBs or DB tables, but I'm not worried about
> that part here.)
>
> Is this possible in the Turbine framework? Anybody got any neat ideas?
>
> Thanks,
>
> ..Ian
>
> -- --- -- --- -- --- -- --- -- --- -- --- -- --- -- --- -- --- -- --- --
> Dr. Ian Beatty beatty@physics.umass.edu
> Physics Education Research Group voice: 413.545.9483
> Department of Physics fax: 413.545.4884
> Univ. of Massachusetts http://umperg.physics.umass.edu/idb/
> Amherst, MA 01003-4525 USA
> -- --- -- --- -- --- -- --- -- --- -- --- -- --- -- --- -- --- -- --- --
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>