RE: [New Functionality] ApplicationResources.properties to DB?

[Jason Rosen]

Isn't dynamic loading of message resources at least half the reason that
people are interested in using a DB to host them?  I know that is a big
factor in my motivation.

-Original Message-
From: Peter A. J. Pilgrim [mailto:[EMAIL PROTECTED]]
Sent: Monday, September 02, 2002 4:53 PM
To: Struts Users Mailing List
Subject: Re: [New Functionality] ApplicationResources.properties to DB?


Ian Vellosa wrote:
> But what do you do each time you add a new language, say German? you need
to
> update the database structure adding a new column? Surely any solution
> should be generic enough not to need that.
> 
> Unfortunately you would need the table to look something more like:
> 
> key   language  value
>     
> global.title  enSomething
> global.title  frquelque chose
> 
> but that will get huge in no time at all! and I doubt that performance
would
> be too good.
> 

Yes The db column design was wrong.

Well how many resources do have or do you need?


Surely you can read the message resource into memory java objects just once.
When you host the web application it is not going to have just 64MB more
like close to 1024 MB of RAM, man! Message Resources are almost singletons
anymore. Therefore you cache the message resource in memory and
do not query the database anymore
unless you really to have ``dynamic message resources''. Now there's
an idea that you can't do with the current static message resources ?


-- 
Peter Pilgrim +-\ +-+++++
Java Technologist | | | ||||| 'n' Shine
   |  O  | | ||  --+| ---+
 /\| ._  / | | \  \ ||
/  \   | | \ \ | |+--  || ---+ A new day
   /_  _\  "Up"| | | | | ||||| is coming
 ||+-+ +-+ +-+++++
http://www.xenonsoft.demon.co.uk/"; />


--
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]>

Re: [New Functionality] ApplicationResources.properties to DB?

[Peter A. J. Pilgrim]

Ian Vellosa wrote:
> But what do you do each time you add a new language, say German? you need to
> update the database structure adding a new column? Surely any solution
> should be generic enough not to need that.
> 
> Unfortunately you would need the table to look something more like:
> 
> key   language  value
>     
> global.title  enSomething
> global.title  frquelque chose
> 
> but that will get huge in no time at all! and I doubt that performance would
> be too good.
> 

Yes The db column design was wrong.

Well how many resources do have or do you need?


Surely you can read the message resource into memory java objects just once.
When you host the web application it is not going to have just 64MB more
like close to 1024 MB of RAM, man! Message Resources are almost singletons
anymore. Therefore you cache the message resource in memory and
do not query the database anymore
unless you really to have ``dynamic message resources''. Now there's
an idea that you can't do with the current static message resources ?


-- 
Peter Pilgrim +-\ +-+++++
Java Technologist | | | ||||| 'n' Shine
   |  O  | | ||  --+| ---+
 /\| ._  / | | \  \ ||
/  \   | | \ \ | |+--  || ---+ A new day
   /_  _\  "Up"| | | | | ||||| is coming
 ||+-+ +-+ +-+++++
http://www.xenonsoft.demon.co.uk/"; />


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [New Functionality] ApplicationResources.properties to DB?

[Peter A. J. Pilgrim]

J
> 
> Another interesting twist -- what if you are using data from the resource
> bundle to make your connectin to the database?  and now you are wanting to
> use JDBCMessageResourceshm.
> 
> What if you rely on another plugin as your persistence layer?
> How would ensure that it gets called first?
> 

Reading more than one message resource entity might solve the problem
as I said before.  The first message resource could be contain
the bootstraping (db configuration) that connects to the second (and third)
message resources? How the protocol will work I dont know,
probably be application dependent.

Just some ideas.


-- 
Peter Pilgrim +-\ +-+++++
Java Technologist | | | ||||| 'n' Shine
   |  O  | | ||  --+| ---+
 /\| ._  / | | \  \ ||
/  \   | | \ \ | |+--  || ---+ A new day
   /_  _\  "Up"| | | | | ||||| is coming
 ||+-+ +-+ +-+++++
http://www.xenonsoft.demon.co.uk/"; />


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [New Functionality] ApplicationResources.properties to DB?

[Peter A. J. Pilgrim]

Eddie Bush wrote:
> James Mitchell wrote:
> 
>> Sorry guys... for not responding earlier.
>>
> 
> 
> Sorry I should have filled you in, James.  I forwarded him the relevant 
> part of your discussion.
> 
>> Also, I'm not sure how many passes I would make over the list, you 
>> certainly
>> wouldn't want a circular reference.
>>
> 
> 
> Since we're talking about a database here:
> 
> Yes, you'd want to avoid circular references.  However, I wouldn't think 
> it would take more than a single pass through the view to churn out all 
> of your resources.  If you used the key as ... *drum roll* ... the key, 
> you could just look it up out of the database.  That's just my initial 
> impression ...
> 

Why not allow the user a choice between recursive and non-recursive
evaluation? It is possible to write code to check the
evaluations are less than a certain limit (say 15)

Has any one here ever programmed with the X Windows / OSF Motif kit mid
1990s?

In X Windows you merge X application resources. You may be want to consider
merging MessageResources?  May be reading the standard web resource and then
read message resources from a DB (or vice versa)?

-- 
Peter Pilgrim +-\ +-+++++
Java Technologist | | | ||||| 'n' Shine
   |  O  | | ||  --+| ---+
 /\| ._  / | | \  \ ||
/  \   | | \ \ | |+--  || ---+ A new day
   /_  _\  "Up"| | | | | ||||| is coming
 ||+-+ +-+ +-+++++
http://www.xenonsoft.demon.co.uk/"; />


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [New Functionality] ApplicationResources.properties to DB?

[Galbreath, Mark]

I thought about writing a db trigger and then decided to include a reload()
to manually refresh the data in the event of changes to the db.

Mark

-Original Message-
From: Jason Rosen [mailto:[EMAIL PROTECTED]]
Sent: Thursday, August 29, 2002 4:23 PM
To: 'Struts Users Mailing List'
Subject: RE: [New Functionality] ApplicationResources.properties to DB?


I was actually hoping to have it implemented where the entire store would be
able to be updated on-the-fly and not have the application cache it on
initialization.  I would at least think that the MessageResources or
MessageResourceFactory implementation would have a reload() method so the
entire app didn't need to be reloaded
to update the cached properties.  This type of thing could even be
configurable (like Craig suggested).

-Original Message-
From: Galbreath, Mark [mailto:[EMAIL PROTECTED]]
Sent: Thursday, August 29, 2002 12:25 PM
To: 'Struts Users Mailing List'
Subject: RE: [New Functionality] ApplicationResources.properties to DB?


My idea is to gather the properties into a static java.util.Properties
object from a call to a stored procedure and instantiate it in context scope
at application startup using the java -d argument to set the environment and
filename in the system properties.  The properties would then be available
to any calling method, same as if fetching from a textfile.

Mark

-Original Message-
From: Eddie Bush [mailto:[EMAIL PROTECTED]]
Sent: Thursday, August 29, 2002 3:11 PM

I don't know how helpful that would be.  I love it for a persistence 
framework, but it seems like it might possibly be (mega-)over-kill for 
this task.  Although!  ... that would certainly take away any confusion 
about what the table/field names were (just map your classes to your 
tables)!  The down-side would be that, not only would you have to 
instantiate your bundle, but you'd also have to instantiate an object 
for *every single* key/value pair (that got used).

Regards,

Eddie

--
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]>

RE: [New Functionality] ApplicationResources.properties to DB?

[Jason Rosen]

The Locale inheritance functionality Craig is referring to is implemented in
PropertyMessageResources.getMessage(Locale locale, String key).

If all MessageResource implementations are expected to use this logic for
finding keys by Locale, maybe it should be documented in the
MessageResources abstract class so designers of inheriting classes are aware
that they need to implement it. (Not a slam on Craig, just a suggestion)

Jason

-Original Message-
From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
Sent: Thursday, August 29, 2002 1:52 PM
To: Struts Users Mailing List
Subject: RE: [New Functionality] ApplicationResources.properties to DB?




On Thu, 29 Aug 2002, James Mitchell wrote:

> Date: Thu, 29 Aug 2002 16:36:30 -0400
> From: James Mitchell <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> To: Struts Users Mailing List <[EMAIL PROTECTED]>
> Subject: RE: [New Functionality] ApplicationResources.properties to DB?
>
> Isn't this all done after the data is loaded?
>

Not if the data isn't loaded (i.e. cached)  :-)

Craig

> James Mitchell
> Software Engineer\Struts Evangelist
> Struts-Atlanta, the "Open Minded Developer Network"
> http://www.open-tools.org/struts-atlanta
>
>
>
>
> > -Original Message-
> > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, August 29, 2002 4:17 PM
> > To: Struts Users Mailing List
> > Subject: RE: [New Functionality] ApplicationResources.properties to DB?
> >
> >
> >
> >
> > On Thu, 29 Aug 2002, Ian Vellosa wrote:
> >
> > > Date: Thu, 29 Aug 2002 21:54:10 +0200
> > > From: Ian Vellosa <[EMAIL PROTECTED]>
> > > Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> > > To: Struts Users Mailing List <[EMAIL PROTECTED]>
> > > Subject: RE: [New Functionality] ApplicationResources.properties to
DB?
> > >
> > > But what do you do each time you add a new language, say
> > German? you need to
> > > update the database structure adding a new column? Surely any solution
> > > should be generic enough not to need that.
> > >
> > > Unfortunately you would need the table to look something more like:
> > >
> > > key   language  value
> > >     
> > > global.title  enSomething
> > > global.title  frquelque chose
> > >
> > > but that will get huge in no time at all! and I doubt that
> > performance would
> > > be too good.
> > >
> >
> > Performance shouldn't be an issue if you index on both key and language.
> >
> > Don't forget to implement the inheritance rules for Locales, such that
if
> > the user's Locale is "en_US" you search for language="en_US", then
> > language="en", then the default.
> >
> > Craig
> >
> >
> > >
> > > -Original Message-
> > > From: James Mitchell [mailto:[EMAIL PROTECTED]]
> > >
> > > > -Original Message-
> > > > From: Eddie Bush [mailto:[EMAIL PROTECTED]]
> > > >
> > > > James Mitchell wrote:
> > > >
> > > > >Sorry guys... for not responding earlier.
> > > > >
> > > > 
> > > >
> > > > Sorry I should have filled you in, James.  I forwarded him
> > the relevant
> > > > part of your discussion.
> > > >
> > > > >Also, I'm not sure how many passes I would make over the list,
> > > > you certainly
> > > > >wouldn't want a circular reference.
> > > > >
> > > > 
> > > >
> > > > Since we're talking about a database here:
> > > >
> > > > Yes, you'd want to avoid circular references.  However, I
> > wouldn't think
> > > > it would take more than a single pass through the view to
> > churn out all
> > > > of your resources.  If you used the key as ... *drum roll*
> > ... the key,
> > > > you could just look it up out of the database.  That's just my
initial
> > > > impression ...
> > >
> > > Well, I was thinking something more abstract.  You shouldn't
> > rely on being
> > > able to have a key (in the JDBC sense).  After all, the storage
> > might be a
> > > single table like this:
> > >
> > > keyen   en_US  fr
> > > -  ---  -- --
> > > global.title   Something(null) quelque chose
> > >
> > >
> > > ...or it could be a very complicated structure based off of a
> > "previously
> > > data driven ASP site" with a simple view giving you your info.
> > >
> > >
> > >
> > >
> > > --
> > > 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]>

RE: [New Functionality] ApplicationResources.properties to DB?

[Craig R. McClanahan]

On Thu, 29 Aug 2002, James Mitchell wrote:

> Date: Thu, 29 Aug 2002 16:36:30 -0400
> From: James Mitchell <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> To: Struts Users Mailing List <[EMAIL PROTECTED]>
> Subject: RE: [New Functionality] ApplicationResources.properties to DB?
>
> Isn't this all done after the data is loaded?
>

Not if the data isn't loaded (i.e. cached)  :-)

Craig

> James Mitchell
> Software Engineer\Struts Evangelist
> Struts-Atlanta, the "Open Minded Developer Network"
> http://www.open-tools.org/struts-atlanta
>
>
>
>
> > -Original Message-
> > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, August 29, 2002 4:17 PM
> > To: Struts Users Mailing List
> > Subject: RE: [New Functionality] ApplicationResources.properties to DB?
> >
> >
> >
> >
> > On Thu, 29 Aug 2002, Ian Vellosa wrote:
> >
> > > Date: Thu, 29 Aug 2002 21:54:10 +0200
> > > From: Ian Vellosa <[EMAIL PROTECTED]>
> > > Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> > > To: Struts Users Mailing List <[EMAIL PROTECTED]>
> > > Subject: RE: [New Functionality] ApplicationResources.properties to DB?
> > >
> > > But what do you do each time you add a new language, say
> > German? you need to
> > > update the database structure adding a new column? Surely any solution
> > > should be generic enough not to need that.
> > >
> > > Unfortunately you would need the table to look something more like:
> > >
> > > key   language  value
> > >     
> > > global.title  enSomething
> > > global.title  frquelque chose
> > >
> > > but that will get huge in no time at all! and I doubt that
> > performance would
> > > be too good.
> > >
> >
> > Performance shouldn't be an issue if you index on both key and language.
> >
> > Don't forget to implement the inheritance rules for Locales, such that if
> > the user's Locale is "en_US" you search for language="en_US", then
> > language="en", then the default.
> >
> > Craig
> >
> >
> > >
> > > -Original Message-
> > > From: James Mitchell [mailto:[EMAIL PROTECTED]]
> > >
> > > > -Original Message-
> > > > From: Eddie Bush [mailto:[EMAIL PROTECTED]]
> > > >
> > > > James Mitchell wrote:
> > > >
> > > > >Sorry guys... for not responding earlier.
> > > > >
> > > > 
> > > >
> > > > Sorry I should have filled you in, James.  I forwarded him
> > the relevant
> > > > part of your discussion.
> > > >
> > > > >Also, I'm not sure how many passes I would make over the list,
> > > > you certainly
> > > > >wouldn't want a circular reference.
> > > > >
> > > > 
> > > >
> > > > Since we're talking about a database here:
> > > >
> > > > Yes, you'd want to avoid circular references.  However, I
> > wouldn't think
> > > > it would take more than a single pass through the view to
> > churn out all
> > > > of your resources.  If you used the key as ... *drum roll*
> > ... the key,
> > > > you could just look it up out of the database.  That's just my initial
> > > > impression ...
> > >
> > > Well, I was thinking something more abstract.  You shouldn't
> > rely on being
> > > able to have a key (in the JDBC sense).  After all, the storage
> > might be a
> > > single table like this:
> > >
> > > keyen   en_US  fr
> > > -  ---  -- --
> > > global.title   Something(null) quelque chose
> > >
> > >
> > > ...or it could be a very complicated structure based off of a
> > "previously
> > > data driven ASP site" with a simple view giving you your info.
> > >
> > >
> > >
> > >
> > > --
> > > 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]>

RE: [New Functionality] ApplicationResources.properties to DB?

[James Mitchell]

Isn't this all done after the data is loaded?

James Mitchell
Software Engineer\Struts Evangelist
Struts-Atlanta, the "Open Minded Developer Network"
http://www.open-tools.org/struts-atlanta




> -Original Message-
> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, August 29, 2002 4:17 PM
> To: Struts Users Mailing List
> Subject: RE: [New Functionality] ApplicationResources.properties to DB?
>
>
>
>
> On Thu, 29 Aug 2002, Ian Vellosa wrote:
>
> > Date: Thu, 29 Aug 2002 21:54:10 +0200
> > From: Ian Vellosa <[EMAIL PROTECTED]>
> > Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> > To: Struts Users Mailing List <[EMAIL PROTECTED]>
> > Subject: RE: [New Functionality] ApplicationResources.properties to DB?
> >
> > But what do you do each time you add a new language, say
> German? you need to
> > update the database structure adding a new column? Surely any solution
> > should be generic enough not to need that.
> >
> > Unfortunately you would need the table to look something more like:
> >
> > key   language  value
> >     
> > global.title  enSomething
> > global.title  frquelque chose
> >
> > but that will get huge in no time at all! and I doubt that
> performance would
> > be too good.
> >
>
> Performance shouldn't be an issue if you index on both key and language.
>
> Don't forget to implement the inheritance rules for Locales, such that if
> the user's Locale is "en_US" you search for language="en_US", then
> language="en", then the default.
>
> Craig
>
>
> >
> > -Original Message-
> > From: James Mitchell [mailto:[EMAIL PROTECTED]]
> >
> > > -Original Message-
> > > From: Eddie Bush [mailto:[EMAIL PROTECTED]]
> > >
> > > James Mitchell wrote:
> > >
> > > >Sorry guys... for not responding earlier.
> > > >
> > > 
> > >
> > > Sorry I should have filled you in, James.  I forwarded him
> the relevant
> > > part of your discussion.
> > >
> > > >Also, I'm not sure how many passes I would make over the list,
> > > you certainly
> > > >wouldn't want a circular reference.
> > > >
> > > 
> > >
> > > Since we're talking about a database here:
> > >
> > > Yes, you'd want to avoid circular references.  However, I
> wouldn't think
> > > it would take more than a single pass through the view to
> churn out all
> > > of your resources.  If you used the key as ... *drum roll*
> ... the key,
> > > you could just look it up out of the database.  That's just my initial
> > > impression ...
> >
> > Well, I was thinking something more abstract.  You shouldn't
> rely on being
> > able to have a key (in the JDBC sense).  After all, the storage
> might be a
> > single table like this:
> >
> > keyen   en_US  fr
> > -  ---  -- --
> > global.title   Something(null) quelque chose
> >
> >
> > ...or it could be a very complicated structure based off of a
> "previously
> > data driven ASP site" with a simple view giving you your info.
> >
> >
> >
> >
> > --
> > 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]>

RE: [New Functionality] ApplicationResources.properties to DB?

[Jason Rosen]

I was actually hoping to have it implemented where the entire store would be
able to be updated on-the-fly and not have the application cache it on
initialization.  I would at least think that the MessageResources or
MessageResourceFactory implementation would have a reload() method so the
entire app didn't need to be reloaded
to update the cached properties.  This type of thing could even be
configurable (like Craig suggested).

-Original Message-
From: Galbreath, Mark [mailto:[EMAIL PROTECTED]]
Sent: Thursday, August 29, 2002 12:25 PM
To: 'Struts Users Mailing List'
Subject: RE: [New Functionality] ApplicationResources.properties to DB?


My idea is to gather the properties into a static java.util.Properties
object from a call to a stored procedure and instantiate it in context scope
at application startup using the java -d argument to set the environment and
filename in the system properties.  The properties would then be available
to any calling method, same as if fetching from a textfile.

Mark

-Original Message-
From: Eddie Bush [mailto:[EMAIL PROTECTED]]
Sent: Thursday, August 29, 2002 3:11 PM

I don't know how helpful that would be.  I love it for a persistence 
framework, but it seems like it might possibly be (mega-)over-kill for 
this task.  Although!  ... that would certainly take away any confusion 
about what the table/field names were (just map your classes to your 
tables)!  The down-side would be that, not only would you have to 
instantiate your bundle, but you'd also have to instantiate an object 
for *every single* key/value pair (that got used).

Regards,

Eddie

--
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]>

RE: [New Functionality] ApplicationResources.properties to DB?

[Craig R. McClanahan]

On Thu, 29 Aug 2002, Ian Vellosa wrote:

> Date: Thu, 29 Aug 2002 21:54:10 +0200
> From: Ian Vellosa <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> To: Struts Users Mailing List <[EMAIL PROTECTED]>
> Subject: RE: [New Functionality] ApplicationResources.properties to DB?
>
> But what do you do each time you add a new language, say German? you need to
> update the database structure adding a new column? Surely any solution
> should be generic enough not to need that.
>
> Unfortunately you would need the table to look something more like:
>
> key   language  value
>     
> global.title  enSomething
> global.title  frquelque chose
>
> but that will get huge in no time at all! and I doubt that performance would
> be too good.
>

Performance shouldn't be an issue if you index on both key and language.

Don't forget to implement the inheritance rules for Locales, such that if
the user's Locale is "en_US" you search for language="en_US", then
language="en", then the default.

Craig


>
> -Original Message-
> From: James Mitchell [mailto:[EMAIL PROTECTED]]
>
> > -Original Message-
> > From: Eddie Bush [mailto:[EMAIL PROTECTED]]
> >
> > James Mitchell wrote:
> >
> > >Sorry guys... for not responding earlier.
> > >
> > 
> >
> > Sorry I should have filled you in, James.  I forwarded him the relevant
> > part of your discussion.
> >
> > >Also, I'm not sure how many passes I would make over the list,
> > you certainly
> > >wouldn't want a circular reference.
> > >
> > 
> >
> > Since we're talking about a database here:
> >
> > Yes, you'd want to avoid circular references.  However, I wouldn't think
> > it would take more than a single pass through the view to churn out all
> > of your resources.  If you used the key as ... *drum roll* ... the key,
> > you could just look it up out of the database.  That's just my initial
> > impression ...
>
> Well, I was thinking something more abstract.  You shouldn't rely on being
> able to have a key (in the JDBC sense).  After all, the storage might be a
> single table like this:
>
> keyen   en_US  fr
> -  ---  -- --
> global.title   Something(null) quelque chose
>
>
> ...or it could be a very complicated structure based off of a "previously
> data driven ASP site" with a simple view giving you your info.
>
>
>
>
> --
> 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]>

RE: [New Functionality] ApplicationResources.properties to DB?

[Ian Vellosa]

But what do you do each time you add a new language, say German? you need to
update the database structure adding a new column? Surely any solution
should be generic enough not to need that.

Unfortunately you would need the table to look something more like:

key   language  value
    
global.title  enSomething
global.title  frquelque chose

but that will get huge in no time at all! and I doubt that performance would
be too good.


-Original Message-
From: James Mitchell [mailto:[EMAIL PROTECTED]]

> -Original Message-
> From: Eddie Bush [mailto:[EMAIL PROTECTED]]
>
> James Mitchell wrote:
>
> >Sorry guys... for not responding earlier.
> >
> 
>
> Sorry I should have filled you in, James.  I forwarded him the relevant
> part of your discussion.
>
> >Also, I'm not sure how many passes I would make over the list,
> you certainly
> >wouldn't want a circular reference.
> >
> 
>
> Since we're talking about a database here:
>
> Yes, you'd want to avoid circular references.  However, I wouldn't think
> it would take more than a single pass through the view to churn out all
> of your resources.  If you used the key as ... *drum roll* ... the key,
> you could just look it up out of the database.  That's just my initial
> impression ...

Well, I was thinking something more abstract.  You shouldn't rely on being
able to have a key (in the JDBC sense).  After all, the storage might be a
single table like this:

keyen   en_US  fr
-  ---  -- --
global.title   Something(null) quelque chose


...or it could be a very complicated structure based off of a "previously
data driven ASP site" with a simple view giving you your info.




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [New Functionality] ApplicationResources.properties to DB?

[James Mitchell]

> -Original Message-
> From: Eddie Bush [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, August 29, 2002 3:11 PM
> To: Struts Users Mailing List
> Subject: Re: [New Functionality] ApplicationResources.properties to DB?
>
>
> James Mitchell wrote:
>
> >Sorry guys... for not responding earlier.
> >
> 
>
> Sorry I should have filled you in, James.  I forwarded him the relevant
> part of your discussion.
>
> >Also, I'm not sure how many passes I would make over the list,
> you certainly
> >wouldn't want a circular reference.
> >
> 
>
> Since we're talking about a database here:
>
> Yes, you'd want to avoid circular references.  However, I wouldn't think
> it would take more than a single pass through the view to churn out all
> of your resources.  If you used the key as ... *drum roll* ... the key,
> you could just look it up out of the database.  That's just my initial
> impression ...

Well, I was thinking something more abstract.  You shouldn't rely on being
able to have a key (in the JDBC sense).  After all, the storage might be a
single table like this:

keyen   en_US  fr
-  ---  -- --
global.title   Something(null) quelque chose


...or it could be a very complicated structure based off of a "previously
data driven ASP site" with a simple view giving you your info.



>
> >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.
> >
> 
>
> I don't know how helpful that would be.  I love it for a persistence
> framework, but it seems like it might possibly be (mega-)over-kill for
> this task.  Although!  ... that would certainly take away any confusion
> about what the table/field names were (just map your classes to your
> tables)!  The down-side would be that, not only would you have to
> instantiate your bundle, but you'd also have to instantiate an object
> for *every single* key/value pair (that got used).
>
> Regards,
>
> Eddie
>
>

Another interesting twist -- what if you are using data from the resource
bundle to make your connectin to the database?  and now you are wanting to
use JDBCMessageResourceshm.

What if you rely on another plugin as your persistence layer?
How would ensure that it gets called first?

James Mitchell
Software Engineer\Struts Evangelist
Struts-Atlanta, the "Open Minded Developer Network"
http://www.open-tools.org/struts-atlanta


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: [New Functionality] ApplicationResources.properties to DB?

[Galbreath, Mark]

My idea is to gather the properties into a static java.util.Properties
object from a call to a stored procedure and instantiate it in context scope
at application startup using the java -d argument to set the environment and
filename in the system properties.  The properties would then be available
to any calling method, same as if fetching from a textfile.

Mark

-Original Message-
From: Eddie Bush [mailto:[EMAIL PROTECTED]]
Sent: Thursday, August 29, 2002 3:11 PM

I don't know how helpful that would be.  I love it for a persistence 
framework, but it seems like it might possibly be (mega-)over-kill for 
this task.  Although!  ... that would certainly take away any confusion 
about what the table/field names were (just map your classes to your 
tables)!  The down-side would be that, not only would you have to 
instantiate your bundle, but you'd also have to instantiate an object 
for *every single* key/value pair (that got used).

Regards,

Eddie

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [New Functionality] ApplicationResources.properties to DB?

[Eddie Bush]

James Mitchell wrote:

>Sorry guys... for not responding earlier.
>


Sorry I should have filled you in, James.  I forwarded him the relevant 
part of your discussion.

>Also, I'm not sure how many passes I would make over the list, you certainly
>wouldn't want a circular reference.
>


Since we're talking about a database here:

Yes, you'd want to avoid circular references.  However, I wouldn't think 
it would take more than a single pass through the view to churn out all 
of your resources.  If you used the key as ... *drum roll* ... the key, 
you could just look it up out of the database.  That's just my initial 
impression ...

>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.
>


I don't know how helpful that would be.  I love it for a persistence 
framework, but it seems like it might possibly be (mega-)over-kill for 
this task.  Although!  ... that would certainly take away any confusion 
about what the table/field names were (just map your classes to your 
tables)!  The down-side would be that, not only would you have to 
instantiate your bundle, but you'd also have to instantiate an object 
for *every single* key/value pair (that got used).

Regards,

Eddie



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [New Functionality] ApplicationResources.properties to DB?

[Galbreath, Mark]

Sure!

-Original Message-
From: James Mitchell [mailto:[EMAIL PROTECTED]]
Sent: Thursday, August 29, 2002 3:04 PM

Also let me know if you want help getting a
JDBCMessageResources using OJB rolling.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [New Functionality] ApplicationResources.properties to DB?

[James Mitchell]

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}{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]>

RE: [New Functionality] ApplicationResources.properties to DB?

[Galbreath, Mark]

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]>

RE: ApplicationResources.properties to DB?

[Jason Rosen]

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]>

RE: AW: ApplicationResources.properties to DB?

[Galbreath, Mark]

Well, I've convinced the team to let me give it a shot, so I'll let you
know; It should only take a couple of days, since I can devote all my
attention to it (well, all that's not spent on [OT] threads here!).

Mark

-Original Message-
From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
Sent: Thursday, August 29, 2002 11:08 AM
To: Struts Users Mailing List
Subject: RE: AW: ApplicationResources.properties to DB?




On Thu, 29 Aug 2002, Galbreath, Mark wrote:

> Date: Thu, 29 Aug 2002 11:01:29 -0400
> From: "Galbreath, Mark" <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> To: 'Struts Users Mailing List' <[EMAIL PROTECTED]>
> Subject: RE: AW: ApplicationResources.properties to DB?
>
> Well, I'm gonna try it...James?  Your thoughts?
>

If you (or anyone else) actually builds one of these things, I'll happily
post it into the "contrib" area so that it gets included in the source
distribution 

Craig


> -Original Message-
> From: Eddie Bush [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, August 29, 2002 10:54 AM
> To: Struts Users Mailing List
> Subject: Re: AW: ApplicationResources.properties to DB?
>
>
> I was seriously lookint at doing JDBCMessageResources back when we
> talked about it.  Unfortunately, my time constraints don't give me much
> "mobility" right now ...  Feel free to build it and contribute it!  As I
> said to Mark, talk to James Mitchell before you get along too far in
> building it - he has some very good ideas for substantially increasing
> the functionality.
>
> Regards,
>
> Eddie
>
> Juraj Lenharcik wrote:
>
> >Hi,
> >
> >is this feature provided for the next releases? I mean this feature
should
> >be supported. There should be at least connectors for databases and
> >xml-application ressources (like in ant, the xml property files).
> >
> >Juraj
> >
>
>
>
> --
> 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]>

RE: AW: ApplicationResources.properties to DB?

[Craig R. McClanahan]

On Thu, 29 Aug 2002, Mark Kaye wrote:

> Date: Thu, 29 Aug 2002 16:09:24 +0100
> From: Mark Kaye <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> To: Struts Users Mailing List <[EMAIL PROTECTED]>
> Subject: RE: AW: ApplicationResources.properties to DB?
>
> > -Original Message-
> > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> >
> > If you (or anyone else) actually builds one of these things,
> > I'll happily post it into the "contrib" area so that it gets
> > included in the source distribution 
>
> That would be great.  I was thinking that this would be an ideal
> solution for my work too.  I wonder what the differences would be
> between parsing a very large ApplicationResources.properties and a
> database table with the appropriate entries.  I assume that all this
> stuff is cached at startup by Struts.  Is this the case?
>


Use the Source, Luke ...


In particular, the sources to the following org.apache.struts.util classes
will be very useful to you:
- MessageResources
- MessageResourcesFactory
- PropertyMessageResources
- PropertyMessageResourcesFactory

The default implementation (PropertyMessageResources) caches the resources
in memory the first time you access a particular file.  The proposed
JDBCMessageResources would have to make its own decisions about whether to
cache or not -- perhaps as a configuration option.

You would probably also want to be flexible about how the database
connection is established, what the table and column names are, and so on
-- for some ideas about configuration, take a look at how JDBCRealm is
configured in Tomcat.

Craig


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: AW: ApplicationResources.properties to DB?

[Eddie Bush]

Mark Kaye wrote:

>>-Original Message-
>>From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] 
>>
>>If you (or anyone else) actually builds one of these things, 
>>I'll happily post it into the "contrib" area so that it gets 
>>included in the source distribution 
>>
>That would be great.  I was thinking that this would be an ideal
>solution for my work too.  I wonder what the differences would be
>between parsing a very large ApplicationResources.properties and a
>database table with the appropriate entries.  I assume that all this
>stuff is cached at startup by Struts.  Is this the case?
>
Yes, it is.




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: AW: ApplicationResources.properties to DB?

[Mark Kaye]

> -Original Message-
> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] 
>
> If you (or anyone else) actually builds one of these things, 
> I'll happily post it into the "contrib" area so that it gets 
> included in the source distribution 

That would be great.  I was thinking that this would be an ideal
solution for my work too.  I wonder what the differences would be
between parsing a very large ApplicationResources.properties and a
database table with the appropriate entries.  I assume that all this
stuff is cached at startup by Struts.  Is this the case?

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: AW: ApplicationResources.properties to DB?

[Craig R. McClanahan]

On Thu, 29 Aug 2002, Galbreath, Mark wrote:

> Date: Thu, 29 Aug 2002 11:01:29 -0400
> From: "Galbreath, Mark" <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> To: 'Struts Users Mailing List' <[EMAIL PROTECTED]>
> Subject: RE: AW: ApplicationResources.properties to DB?
>
> Well, I'm gonna try it...James?  Your thoughts?
>

If you (or anyone else) actually builds one of these things, I'll happily
post it into the "contrib" area so that it gets included in the source
distribution 

Craig


> -Original Message-
> From: Eddie Bush [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, August 29, 2002 10:54 AM
> To: Struts Users Mailing List
> Subject: Re: AW: ApplicationResources.properties to DB?
>
>
> I was seriously lookint at doing JDBCMessageResources back when we
> talked about it.  Unfortunately, my time constraints don't give me much
> "mobility" right now ...  Feel free to build it and contribute it!  As I
> said to Mark, talk to James Mitchell before you get along too far in
> building it - he has some very good ideas for substantially increasing
> the functionality.
>
> Regards,
>
> Eddie
>
> Juraj Lenharcik wrote:
>
> >Hi,
> >
> >is this feature provided for the next releases? I mean this feature should
> >be supported. There should be at least connectors for databases and
> >xml-application ressources (like in ant, the xml property files).
> >
> >Juraj
> >
>
>
>
> --
> 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]>

RE: AW: ApplicationResources.properties to DB?

[Galbreath, Mark]

Well, I'm gonna try it...James?  Your thoughts?

-Original Message-
From: Eddie Bush [mailto:[EMAIL PROTECTED]]
Sent: Thursday, August 29, 2002 10:54 AM
To: Struts Users Mailing List
Subject: Re: AW: ApplicationResources.properties to DB?


I was seriously lookint at doing JDBCMessageResources back when we 
talked about it.  Unfortunately, my time constraints don't give me much 
"mobility" right now ...  Feel free to build it and contribute it!  As I 
said to Mark, talk to James Mitchell before you get along too far in 
building it - he has some very good ideas for substantially increasing 
the functionality.

Regards,

Eddie

Juraj Lenharcik wrote:

>Hi,
>
>is this feature provided for the next releases? I mean this feature should
>be supported. There should be at least connectors for databases and
>xml-application ressources (like in ant, the xml property files).  
>
>Juraj
>



--
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]>

RE: ApplicationResources.properties to DB?

[Galbreath, Mark]

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]>

Re: AW: ApplicationResources.properties to DB?

[Eddie Bush]

I was seriously lookint at doing JDBCMessageResources back when we 
talked about it.  Unfortunately, my time constraints don't give me much 
"mobility" right now ...  Feel free to build it and contribute it!  As I 
said to Mark, talk to James Mitchell before you get along too far in 
building it - he has some very good ideas for substantially increasing 
the functionality.

Regards,

Eddie

Juraj Lenharcik wrote:

>Hi,
>
>is this feature provided for the next releases? I mean this feature should
>be supported. There should be at least connectors for databases and
>xml-application ressources (like in ant, the xml property files).  
>
>Juraj
>



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

AW: ApplicationResources.properties to DB?

[Juraj Lenharcik]

Hi,

is this feature provided for the next releases? I mean this feature should
be supported. There should be at least connectors for databases and
xml-application ressources (like in ant, the xml property files).  



Juraj


-Ursprüngliche Nachricht-
Von: Tero P Paananen [mailto:[EMAIL PROTECTED]]
Gesendet: Donnerstag, 29. August 2002 16:41
An: Struts Users Mailing List
Betreff: RE: ApplicationResources.properties to DB?


> 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.

This was discussed, briefly, a few months ago.

It would be very easy to extend the MessageResources classes
in Struts to read from a database instead of properties file.

All you need to do is extent PropertyMessageResources and
overload the loadLocale() method.

-TPP

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: ApplicationResources.properties to DB?

[Eddie Bush]

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:   
For additional commands, e-mail: 

RE: ApplicationResources.properties to DB?

[Tero P Paananen]

> 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.

This was discussed, briefly, a few months ago.

It would be very easy to extend the MessageResources classes
in Struts to read from a database instead of properties file.

All you need to do is extent PropertyMessageResources and
overload the loadLocale() method.

-TPP


<>
--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

ApplicationResources.properties to DB?

[Galbreath, Mark]

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 = ( - ? ))!"