You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by Michael Jouravlev <jm...@gmail.com> on 2005/12/01 02:28:56 UTC
[RESOURCES] Messages vs. regular properties
Do I miss something or messages and resources are incompatible? From
my point of view they are basically the same thing. Differences are:
* resources can be anything, messages can be only strings
* messages take parameters to stick into placeholders
So why two sets of classes, which are so different? For example, I was
able to easily load message from property file located in the
classpath, but I could not do the same treating message as resource,
because current API does not search in classpath. Or does it? Locale
is not optional, should it be?
Maybe it is possible to introduce Property class, make Message
subclass of Property. Ditch Messages class and create one Properties
class (or some other name) that holds both properties and messages and
whatnot.
At any rate, the usage of properties and messages should be identical.
Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [RESOURCES] Messages vs. regular properties
Posted by Michael Jouravlev <jm...@gmail.com>.
On 12/1/05, Craig McClanahan <cr...@apache.org> wrote:
> On 12/1/05, Michael Jouravlev <jm...@gmail.com> wrote:
> > Umm... So you are saying that I should use Message(s) for both error
> > messages and regular localised strings. Makes sense. How about
> > Messages to implement List? I know it sucks to implement all List
> > methods, but JSTL calls get("bla") for lists if I use something like
> > ${list["bla"]} in my JSP page. I think it would really simplify
> > things, because now I have to write
> > <li><i>
> > <%= ((Messages)session.getAttribute("MSGS")).getMessage("label.user") %>
> > </i></li>
> > which is OK, but too long. Or maybe you can suggest a better way to
> > display messages?
>
>
> Even with JSTL expressions, I think a Map would be more useful than a List.
(1) Messages implements Map
I made Messages implementing Map. Most methods are stubs throwing an
exception, but I think they should not be. Why Messages and Resources
do not implement a collection anyway?
I implemented Object Map::get(Object key) like this:
public Object get(Object key) {
if (key == null) return null;
if (!(key instanceof String)) return null;
return (getMessage(resources, (String) key));
}
Works like a charm, now I am able to write stuff like this:
msgs = Messages.getMessages("AppResources");
session.setAttribute("MSGS", msgs);
<html>
<h3><c:out value='${MSGS["heading.login"]}'/></h3>
</html>
where file \WEB-INF\classes\AppResources.properties contains:
heading.login=Log In
(2) Messages and Locale
If I understand correctly, static method getMessages() does not
support locale. But creating resource factory is a huge deal. I would
like to have getMessages() supporting locale. Actually, I would like
Messages accepting locale as "current" and saving it for future use
until it is changed by a user.
On 12/1/05, Craig McClanahan <cr...@apache.org> wrote:
> On 12/1/05, Michael Jouravlev <jm...@gmail.com> wrote:
> >
> > On 12/1/05, Craig McClanahan <cr...@apache.org> wrote:
> > > Even with JSTL expressions, I think a Map would be more useful than a
> > List.
> >
> > Yes, of course Map is better. Thanks for correction, Craig.
> >
> > Btw, seems like ResourcesFactoryBase which is used in Messages, caches
> > resources in memory. This makes things faster, but I prefer this to be
> > configurable, so we would not have the "reloadable resources" problem.
>
>
> You can deal with "reloadable resources" by either overriding the caching
> (what the JDBC resources factory should do), or implementing a side
> mechanism that watches for file changes and reloads the underlying resources
> on the fly.
What I was talking about is that instead of listening to file changes
not cache messages at all. I mean, if I read them from messages object
- get them from memory. If I create messages object or I create a
factory object - read them from file or whatever other source *every
time*.
> Note that, if you use the ResourceBundle implementation, the JDK is going to
> cache these things anyway, if if we don't here.
Are you saying that when I read from a bundle, JDK caches all content
of property file in memory and does not access file for consecutive
reads? Really? I have to verify that, but that would be very
inconvenient.
Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [RESOURCES] Messages vs. regular properties
Posted by Craig McClanahan <cr...@apache.org>.
On 12/1/05, Michael Jouravlev <jm...@gmail.com> wrote:
>
> On 12/1/05, Craig McClanahan <cr...@apache.org> wrote:
> > Even with JSTL expressions, I think a Map would be more useful than a
> List.
>
> Yes, of course Map is better. Thanks for correction, Craig.
>
> Btw, seems like ResourcesFactoryBase which is used in Messages, caches
> resources in memory. This makes things faster, but I prefer this to be
> configurable, so we would not have the "reloadable resources" problem.
You can deal with "reloadable resources" by either overriding the caching
(what the JDBC resources factory should do), or implementing a side
mechanism that watches for file changes and reloads the underlying resources
on the fly.
Note that, if you use the ResourceBundle implementation, the JDK is going to
cache these things anyway, if if we don't here.
Michael.
Craig
Re: [RESOURCES] Messages vs. regular properties
Posted by Michael Jouravlev <jm...@gmail.com>.
On 12/1/05, Craig McClanahan <cr...@apache.org> wrote:
> Even with JSTL expressions, I think a Map would be more useful than a List.
Yes, of course Map is better. Thanks for correction, Craig.
Btw, seems like ResourcesFactoryBase which is used in Messages, caches
resources in memory. This makes things faster, but I prefer this to be
configurable, so we would not have the "reloadable resources" problem.
Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [RESOURCES] Messages vs. regular properties
Posted by Craig McClanahan <cr...@apache.org>.
On 12/1/05, Michael Jouravlev <jm...@gmail.com> wrote:
>
> On 11/30/05, Niall Pemberton <ni...@gmail.com> wrote:
> > On 12/1/05, Michael Jouravlev <jm...@gmail.com> wrote:
> > > Do I miss something or messages and resources are incompatible? From
> > > my point of view they are basically the same thing. Differences are:
> > >
> > > * resources can be anything, messages can be only strings
> > > * messages take parameters to stick into placeholders
> >
> > If were talking in Commons Resources terms then Resources and Message
> > are different things - a Message is the representation of the key to a
> > resource - Resources are what resolve those keys into the resource
> > object.
>
> Umm... So you are saying that I should use Message(s) for both error
> messages and regular localised strings. Makes sense. How about
> Messages to implement List? I know it sucks to implement all List
> methods, but JSTL calls get("bla") for lists if I use something like
> ${list["bla"]} in my JSP page. I think it would really simplify
> things, because now I have to write
> <li><i>
> <%= ((Messages)session.getAttribute("MSGS")).getMessage("label.user") %>
> </i></li>
> which is OK, but too long. Or maybe you can suggest a better way to
> display messages?
FWIW, JavaServer Faces addresses this by exposing a resource bundle as a Map
(not a List):
<f:loadBundle var="messages" bundlename="
com.mycompany.mypackage.Messages"/>
so you can say things like:
<h:outputLabel for="username" value="#{messages['label.user']}"/>
Even with JSTL expressions, I think a Map would be more useful than a List.
Michael.
Craig
Re: [RESOURCES] Messages vs. regular properties
Posted by Michael Jouravlev <jm...@gmail.com>.
On 11/30/05, Niall Pemberton <ni...@gmail.com> wrote:
> On 12/1/05, Michael Jouravlev <jm...@gmail.com> wrote:
> > Do I miss something or messages and resources are incompatible? From
> > my point of view they are basically the same thing. Differences are:
> >
> > * resources can be anything, messages can be only strings
> > * messages take parameters to stick into placeholders
>
> If were talking in Commons Resources terms then Resources and Message
> are different things - a Message is the representation of the key to a
> resource - Resources are what resolve those keys into the resource
> object.
Umm... So you are saying that I should use Message(s) for both error
messages and regular localised strings. Makes sense. How about
Messages to implement List? I know it sucks to implement all List
methods, but JSTL calls get("bla") for lists if I use something like
${list["bla"]} in my JSP page. I think it would really simplify
things, because now I have to write
<li><i>
<%= ((Messages)session.getAttribute("MSGS")).getMessage("label.user") %>
</i></li>
which is OK, but too long. Or maybe you can suggest a better way to
display messages?
Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [RESOURCES] Messages vs. regular properties
Posted by Niall Pemberton <ni...@gmail.com>.
On 12/1/05, Michael Jouravlev <jm...@gmail.com> wrote:
> Do I miss something or messages and resources are incompatible? From
> my point of view they are basically the same thing. Differences are:
>
> * resources can be anything, messages can be only strings
> * messages take parameters to stick into placeholders
If were talking in Commons Resources terms then Resources and Message
are different things - a Message is the representation of the key to a
resource - Resources are what resolve those keys into the resource
object.
Messages is a convenience class provided to do the following processing:
1) Resolve a resources key into its String value
2) Do parametric replacement of arguments using MessageFormat
> So why two sets of classes, which are so different? For example, I was
> able to easily load message from property file located in the
> classpath, but I could not do the same treating message as resource,
> because current API does not search in classpath. Or does it? Locale
> is not optional, should it be?
Different resources implementations look for different things
PropertyMessageResources uses a URL to locale properties files. If you
want something different then you can take one of the base
implementations and easily provide your own.
> Maybe it is possible to introduce Property class, make Message
> subclass of Property. Ditch Messages class and create one Properties
> class (or some other name) that holds both properties and messages and
> whatnot.
There are implementations based both on properties files and XML
already - check out the user guide.
Niall
> At any rate, the usage of properties and messages should be identical.
>
> Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org