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.

> 2) A couple of possible suggestions for inclusion in the Message interface:
> > 2.1) Struts has "non resource" messages where the message contains the
> > actual message text, rather than a key to a resource - is it worth
> > adding an "isResource()" method to Message?
>
>
> I guess I'm not seeing the difference ... "resources" in the name of the
> package was intended to support the retrieval of localized string messages
> or non-string resources that correspond to a key.

Yes I agree it seems a strange suggestion but it would mean that
systems/software that allowed either resource or non-resource messages
to use Commons Resources Message/MessagesList types for all their
messages and not need something different for non-resource messages.

> 2.2) Its been requested in Struts that the Message object include the
> > name of the Resources it comes from - that way Messages can contain
> > messages from multiple resources. Is it worth adding a
> > "getResourcesName()" method to the Message interface?
>
>
> Why not have a property of type Resources so you can refer to it directly,
> rather than inventing a new identifier?
>
> It would also be worth thinking through whether one can easily configure
> Resources instances with a dependency injection framework ...

I wasn't thinking of inventing a new indentifier - just using the
existing one in Resources (i,e. its name). I think the main reason for
not injecting a Resources instance would be that it would get
serialized with every Message instance.
Additionally though IMO it would be a negative requirement to have to
get hold of the Resources when creating a message. In Struts terms,
the developer creates a MessageList and throws it back to Struts to
resolve them and doesn't have to worry about how to get hold of
Resources.

> Niall
>
>
> Craig
>
>

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

Reply via email to