Sorry guys... for not responding earlier.
Eddie and I were discussing this very topic a while back and as Craig
mentioned, this should be relatively painless given the pluggable
architecture.
Well, I had a couple ideas for enhancing the usefulness of any particular
MessageResources implementation. One idea I had was to add the ability to
replace text using values from within the same file much like you might do
in a build.xml script.
Example:
global.application.name=James' Really Cool Web Application
global.company.name=Open-Tools.org
global.application.copyright=Copyright 2002 {global.company.name}
footer.label={global.application.name}<br>{global.application.copyright}
...instead of "knowing ahead of time to use {0} with global.application.name
in your code.
Also, I'm not sure how many passes I would make over the list, you certainly
wouldn't want a circular reference. I know if you forward tiles to an
action which forwards to the same (or an including) tile, it will loop a few
times before it detects and moves on (I'm shamefully embarrassed to admit
that I actually did this once ;)
Anyway, I've been searching for my Master-Wish-List that has this idea and a
few others in it. Can't seem to find it on my laptop. I'll send you more
stuff later. Also let me know if you want help getting a
JDBCMessageResources using OJB rolling.
James Mitchell
Software Engineer\Struts Evangelist
Struts-Atlanta, the "Open Minded Developer Network"
http://www.open-tools.org/struts-atlanta
> -----Original Message-----
> From: Galbreath, Mark [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, August 29, 2002 1:00 PM
> To: 'Struts Users Mailing List'
> Subject: RE: [New Functionality] ApplicationResources.properties to DB?
>
>
> I'm looking at the Struts API for the classes suggested by Craig
> and Eddie,
> and then I'll look at the source code to figure out what methods
> to override
> or add. Then I will have to come up with a db schema. All these
> things can
> be done concurrently and results/ideas posted to here to garner feedback.
> Hey! It's open source!
>
> Mark
>
> -----Original Message-----
> From: Jason Rosen [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, August 29, 2002 12:53 PM
> To: 'Struts Users Mailing List'
> Subject: RE: ApplicationResources.properties to DB?
>
>
> If you decide to start developing a DB MessageResouces implementation, I
> would like to contribute - this is functionality I need as well and have
> thought about taking on. Let me know if you need/want any help.
>
> Jason
>
> -----Original Message-----
> From: Galbreath, Mark [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, August 29, 2002 8:00 AM
> To: 'Struts Users Mailing List'
> Subject: RE: ApplicationResources.properties to DB?
>
>
> Outstanding...thanx!
>
> -----Original Message-----
> From: Eddie Bush [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, August 29, 2002 10:46 AM
> To: Struts Users Mailing List
> Subject: Re: ApplicationResources.properties to DB?
>
>
> James and I bandied about this topic some time ago (I think you were
> either out-of-country or on vacation) in response to someone else
> wanting to do exactly the same thing. I think the suggestion Craig put
> forth was to extend MessageResources (ie build JDBCMessageResources).
> Oh, and, if you choose to implement it, you should talk to James
> (Mitchell). He has some very fascinating ideas you may want to
> consider ...
>
> HTH,
>
> Eddie
>
> Galbreath, Mark wrote:
>
> >Has anybody given any thought to (much less actually done it) placing
> >properties files into the database and having the app server load/methods
> >call a persistent bean containing the keys/values? We are developing for
> >different clients using basically the same framework and I am
> thinking that
> >rather than maintain separate properties files in various physical
> >locations, to put the properties into the database, write a Java
> interface
> >defining the extraction methods, and implement concrete classes for each
> app
> >to load that app's properties.
> >
> >Thoughts?
> >
> >Mark
> >"If only I had known this ( T = ( - ? ))!"
> >
> >
>
>
>
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
