I just implemented a very quick (locale-ignorant) lookup of key/value
pairs from a database table (through a commercial O/R mapping library).
It was very simple and works nicely. I added a "context" so that
different webapps - "admin" and "frontend" in our case - have separate
spaces.
All the other issues you've encountered are far more complex than my
projects tight timeline can affod for my poor overtaxed brain! :) But
its very cool you've got a handle on this.
We will likely implement a user interface to allow administrators the
ability to maintain the text resources in a very hierarchical fashion,
such as seeing all resources used by a page (title, for example) and all
resources used for a form (our keys are <formname>.<fieldname>). I also
need to add in the locale stuff eventually but its not of pressing concern.
Thanks for your extensive effort James - we can probably leverage your
work at some point in the near future.
In regards to your close() issue - what I did was pull *all* database
fields in lazily on the first call to getMessage() and build a multi-Map
data structure for fast reference thereafter - so the database is only
ever hit once. I will eventually add something so that the resources
can be refreshed on a live running app. (I've never used Struts data
resources handling, so I cannot comment on that particular piece)
Erik
James Mitchell wrote:
> Great stuff eh?
>
> My DBMessageResources already uses OJB as the persistence layer for my impl
> :)
>
> You simply run the db scripts (or not, if you will use your own), configure
> the OJB files (repository[-*].xml), declare the new factory
> class(struts-config.xml), and specify subapp and key (parameter in
> <message-resources> and you're off!!! (The readme will explain everything)
> I even provide the struts-example modified to demonstrate the new
> functionality.
>
> In order to support sub-applications and multiple bundles per subapp,
> (correct me here if I stray) multiple MessageResourcesConfig instances are
> stored (application scope) and are set into request scope (according to the
> selected application or subapp) during the request.
>
> So, with that in mind, any code needing a message, can grab the
> MessageResources (only having to specify the bundle key) out of the request
> and call getMessage() with whatever replacing params (if any) they have.
>
> See, the MessageResources class has no knowledge of it's existence in a web
> application (Struts or other). In fact, it is configured with a single
> String ("parameter" as mentioned above) and call to its factory. The only
> abstract method call to it is:
>
> getMessage(Locale locale, String key);
>
> How would you determine the correct bundle key (assuming there are no
> subapps), and if there are subapps, how would you determine which one (and
> the bundle for it as well)?
>
> I chose to use the "parameter" to tell me.
>
> syntax: parameter="[subapp].[key]"
>
> example: (using default subapp (empty String..."") and default key
>
> <message-resources
> factory="org.apache.struts.util.DBMessageResourcesFactory"
> parameter="."/>
>
>
>
>
>
> Funny.....this works great if you are caching the key-value pairs in your
> MessageResources class. But if you are trying to get these from a
> database/xml file/whatever, you have to 'work around' this issue.
>
> Additionally, if you depend on lifecycle calls to .... oh, let's say ....
> close a connection, you are just SOOL. And other than modifying the source,
> I see no way around it.
>
> This design issue has had me 'bent over a rail' for a few weeks now, as I
> ponder alternatives.
>
> I have been slowly coming to the conclusion that MessageResources
> implementations might be better off being created by a plugin instead of the
> <message-resources> tag. This would also allow you to use/reuse existing
> resources (e.g. connections that might have been configured in the
> struts-config) and also provides much needed lifecycle calls.
>
> Your thought?
>
>
>
>
> James Mitchell
> Software Engineer/Struts Evangelist
> http://www.open-tools.org
>
>
>
>
>>-----Original Message-----
>>From: Erik Hatcher [mailto:[EMAIL PROTECTED]]
>>Sent: Wednesday, October 09, 2002 12:25 AM
>>To: Jakarta Commons Developers List
>>Subject: Re: Message Resources from database
>>
>>
>>No problem, James. Take your time!
>>
>>I'm going to tinker with a proof-of-concept implementation using our own
>>persistence mechanism rather than pure JDBC (we're using an O/R mapping
>>tool in the middle) and see how quickly I can get something working.
>>
>>I guess the Commons stuff is not in Struts 1.1 yet, so I'll probably
>>build on top of the Struts provided API for now and then refactor to the
>>Commons one when its available.
>>
>>What I'll build will not be generally applicable though since it will be
>>using a commercial O/R mapper, but once James stuff is made available
>>we'll see if there is a way to generalize what I've done or just switch
>>to James code altogether.
>>
>>Thanks,
>> Erik
>>
>>
>>James Mitchell wrote:
>>
>>>>-----Original Message-----
>>>>From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
>>>>Sent: Tuesday, October 08, 2002 7:37 PM
>>>>To: Struts Developers List
>>>>Subject: RE: Message Resources from database
>>>>
>>>>
>>>>
>>>>There was also a message from Erik Hatcher on COMMONS-DEV about adding
>>>>this capability to commons-resources. James, are you subscribed there -
>>>>if not, I can forward a note about your progress.
>>>>
>>>
>>>
>>>That's fine with me, I was planning to donate this anyway, although my
>>>initial implementation supports Strut's sub-apps, so it may need some
>>>refactoring for anything more basic.
>>>
>>>I only have a couple small issues to complete before I post an
>>
>>[ANNOUNCE] to
>>
>>>the users list. In the meantime, I'm also trying to finish up
>>>XMLMessageResources.
>>>
>>>For anyone waiting for either of these, I apologize, I stopped
>>
>>working on
>>
>>>them about a week ago while I was playing around with moving
>>
>>from Win2k to
>>
>>>Mandrake 8.1 on my laptop. I'm still trying to get everything
>>
>>configured
>>
>>>and 'get back into the groove' ;)
>>>
>>>I'll post something as soon as I can.
>>>
>>
>
>
> --
> 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]>
