I've been going about this in the same way (jarring templates and classes separately) and ran into a problem. I wondered if anyone else has come upon this: There are several values in our skin.props file that are module-specific and don't need to be, or belong in, the "core". I was hoping to have different "modName-skin.prop" files but the current UIManager can only reference 1 skin file (skin.props) and that is hard-coded. Basically I want it to work the same as the TR.props files that can reference other files and add/replace values. I guess I'll have to extend it myself but I was wondering if this is something to submit as a new feature or if anyone else has come up with something similar.
As long as I'm on the subject I also have the same problem with resource bundles. I use a lot of i18nized strings and I don't want to fill up the resource bundles with module specific strings that may not be used in all apps. Is there a way to add multiple bundles (myBundle.properties, myBundle2.properties) Thanks, Matt ----- Original Message ----- From: "Brekke, Jeff" <[EMAIL PROTECTED]> To: "'Turbine Users List'" <[EMAIL PROTECTED]> Sent: Thursday, October 17, 2002 3:59 PM Subject: RE: Modular Application Design? > This is what we are currently doing for our sub-applications. Each project > packages up the code and templates into a jar. The jars are pulled into a > main turbine application along with the sub applications configuration file. > We just add an 'include' to the bottom of tr.props for the subapps config. > The module.packages line is also updated. > > It works, but what would really be nice is to extend the functionality to, > as you mention below, allow the jar to be dropped in real time, and the > turbine app auto pick it up. This would need to have the config packaged > into the jar, the module.packages auto-updated, and dynamic updating of > TurbineResources. > > ================================================================= > Jeffrey D. Brekke Quad/Graphics > [EMAIL PROTECTED] http://www.qg.com > > > > -----Original Message----- > > From: Scott Eade [mailto:seade@;backstagetech.com.au] > > Sent: Wednesday, October 16, 2002 6:01 PM > > To: turbine-user > > Subject: Re: Modular Application Design? > > > > > > 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 <[EMAIL PROTECTED]> > > > Reply-To: "Turbine Users List" <[EMAIL PROTECTED]> > > > Date: Wed, 16 Oct 2002 14:09:00 -0400 > > > To: [EMAIL PROTECTED] > > > 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 [EMAIL PROTECTED] > > > 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: > <mailto:turbine-user-unsubscribe@;jakarta.apache.org> > > For additional commands, e-mail: > <mailto:turbine-user-help@;jakarta.apache.org> > > > > > -- > To unsubscribe, e-mail: > <mailto:turbine-user-unsubscribe@;jakarta.apache.org> > For additional commands, e-mail: > <mailto:turbine-user-help@;jakarta.apache.org> > > -- > To unsubscribe, e-mail: <mailto:turbine-user-unsubscribe@;jakarta.apache.org> > For additional commands, e-mail: <mailto:turbine-user-help@;jakarta.apache.org> > -- To unsubscribe, e-mail: <mailto:turbine-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:turbine-user-help@;jakarta.apache.org>
