On 11/28/05, Christian Meder <[EMAIL PROTECTED]> wrote:
> On Mon, 2005-11-28 at 21:43 +0100, Christian Meder wrote:
> > On Mon, 2005-11-28 at 03:00 +0000, Niall Pemberton wrote:
> > > On 11/28/05, Craig McClanahan <[EMAIL PROTECTED]> wrote:
> > > > On 11/27/05, Niall Pemberton <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > A couple of questions I had on the resources API:
> > > > >
> > > > > 1) I was wondering why TimeZone is include in the Resources's content
> > > > > read methods? Is there a use case, for example, for giving west coast
> > > > > Americans a different message to east coast?
> > > >
> > > >
> > > > Some of the format options for displaying times take a time zone 
> > > > parameter
> > > > (so that it can be included in the emitted string).  Simply pass null 
> > > > if it
> > > > doesn't matter to you.
> > >
> > > I don't see any valid formats specified in java.text.MessageFormat
> > > that take a TimeZone. Thats slightly irrelevant though since AFAIK
> > > Commons Resources doesn't deal anywhere with message formats. My
> > > understanding that happends after the resource has been retrieved,
> > > something like....
> > >
> > >     String msgResource = myResources.getString("foo.key", locale, null);
> > >     MessageFormat msgFormat = new MessageFormat(msgResource);
> > >     msgFormat.setLocale(locale);
> > >     String message = msgFormat.format(args);
> > >
> > > Have I got the wrong end of the stick on this? Struts MessageResources
> > > does do the MessageFormat bit, but Commons Resources doesn't.
> >
> > Actually I just nuked my reply (still stuck on my laptop) which
> > reiterated my concern from my mail a couple of days that
> > MessageResources and the MessageFormat stuff is missing like you did.
> > But I guess I found it: it's in Messages.
> >
> > So I guess it should be more along the line:
> >
> > Messages myMsgResources = new Messages(myResources);
> > String message = myMsgResources.getMessage(locale, "foo.key", args);
> >
> > But there are some things which should get improved wrt Messages:
> >
> > * include all parametric replacement options like in Struts
> > MessageResources (not only arg0 and [] args)
>
> Following up to myself:
>
> I just found the following in the log for Messages:
>
>
> r142735 | dgraham | 2003-10-02 02:24:13 +0200 (Thu, 02 Oct 2003) | 8
> lines
> Changed paths:
>
> M 
> /jakarta/commons/proper/resources/trunk/src/java/org/apache/commons/resources/Messages.java
>
> M 
> /jakarta/commons/proper/resources/trunk/src/test/org/apache/commons/resources/MessagesTestCase.java
>
> Removed Messages methods that provided 2-4 replacement
> arguments that were carried over from Struts.  This makes
> the interface easier to understand and the implementation
> simpler.  The methods that are left provide for 0, 1, or an
> array of replacement arguments.
>
> I happen to disagree with the reasoning but I wanted to put this up for
> discussion.

Sorry I didn't respond to your earlier post, don't seem to have enough
hours in the day.

My view is the simpler the better, especially as Messages can be
easily extended to include these additional methods.

> > * the order of locale and key is reversed compared to Resources, it's
> > (locale, key); Resources is (key, locale)

Good point, I agree it should be consistent.

> > * MessageFormat isn't cached as it is in Struts MessageResources

The problem with formats is that they are not thread safe, so caching
them means you need to synchronize the cache. I don't know whether
caching provides any benefit because of that. Also if we set the
Locale as you suggest below, then we would have to cache formats by
locale.

> > * setLocale isn't called on the used MessageFormat instances

I agree we should do this.

> > * the TimeZone parameter isn't used like in the rest of
> > commons-resources

I'm don't know how it could be - and was one of my original questions.

> > If nobody objects I'll whip up patches for the above points.

Dam, I had just got resources down to zero open bugs ;-)

Niall

> > Greetings,
> >
> >
> >                       Christian

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

Reply via email to