You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by sa...@women-at-work.org on 2004/09/26 13:08:48 UTC
Feature request: Global property files/global messages
Hello!
What about having global property files in the next tapestry release?
They could be all loaded in the global object and have getter Methods
with the locale as an argument and optionally arguments to be included in a
localized string.
People could still use the page properties, but additionally, it would
also be possible to work with global properties.
Global.java
public String getMessage(String key, Locale locale) {
if (globalMessages == null) {
this.loadMessages();
}
String localizedMessage =
globalMessages.getProperty("welcome","locale");
return localizedMessage;
}
public String getMessage(String key, Object[] arguments, Locale locale)
{
if (globalMessages == null) {
this.loadMessages();
}
String localizedMessage = globalMessages.getProperty("welcome_user,
"locale");
localizedMessage.format(localizedMessage, arguments); // just as an
example
return localizedMessage;
}
the files could look like:
global.en_UK.properties
global.en_US.properties
etc...
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Passing visit variables as ognl method invocation parameters
Posted by sa...@women-at-work.org.
cooool! :-)
> have you tried:
> attribute="ognl:format(key, visit.userName, visit.userMessages)"
>
> ??
>
> Also, the ognl syntax reference is realy helpful.
>
> Jamie
>
> ----- Original Message -----
> From: <sa...@women-at-work.org>
> To: "Tapestry users" <ta...@jakarta.apache.org>
> Sent: Wednesday, September 29, 2004 4:42 AM
> Subject: Passing visit variables as ognl method invocation parameters
>
>
> > Me again ;-)
> >
> > attribute="ognl:format(key, name, numMessages)"
> >
> > Is it possible to pass variables as parameters using this notation?
> >
> > Such as:
> >
> > attribute="ognl:format(key, ognl:visit.userName,
> ognl:visit.userMessages)"
> >
> > ?
> >
> > Probably not, but how do you pass non-static parameters to a method
> > that is directly called from the template or how do u generally access
> > ognl values that are within the ognl method invocation?
> >
> >
> > :-/
> >
> > ________________
> > > It would be nice if <message-binding> (or even something like
> > > attribute="message:key;val1;val2") supported the parametric
> > > substitutions, but it does not. The only way I know of to get the
> > > curly bracket stuff to work would be to do this:
> > >
> > > attribute="ognl:format(key, name, numMessages)"
> > >
> > > That's not so bad, though. Look at the various signatures for
> format()
> > > for other variations. Not much different than what you were going to
> > > implement anyway, and you get the added benefit of page specific
> > > messages overriding global ones (if your implementation is clever
> > > enough!) and that your global messages will be automatically supported
> > > in all of Tapestry's resource handling features.
> > >
> > > Erik
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Passing visit variables as ognl method invocation parameters
Posted by Jamie Orchard-Hays <ja...@dang.com>.
have you tried:
attribute="ognl:format(key, visit.userName, visit.userMessages)"
??
Also, the ognl syntax reference is realy helpful.
Jamie
----- Original Message -----
From: <sa...@women-at-work.org>
To: "Tapestry users" <ta...@jakarta.apache.org>
Sent: Wednesday, September 29, 2004 4:42 AM
Subject: Passing visit variables as ognl method invocation parameters
> Me again ;-)
>
> attribute="ognl:format(key, name, numMessages)"
>
> Is it possible to pass variables as parameters using this notation?
>
> Such as:
>
> attribute="ognl:format(key, ognl:visit.userName, ognl:visit.userMessages)"
>
> ?
>
> Probably not, but how do you pass non-static parameters to a method
> that is directly called from the template or how do u generally access
> ognl values that are within the ognl method invocation?
>
>
> :-/
>
> ________________
> > It would be nice if <message-binding> (or even something like
> > attribute="message:key;val1;val2") supported the parametric
> > substitutions, but it does not. The only way I know of to get the
> > curly bracket stuff to work would be to do this:
> >
> > attribute="ognl:format(key, name, numMessages)"
> >
> > That's not so bad, though. Look at the various signatures for format()
> > for other variations. Not much different than what you were going to
> > implement anyway, and you get the added benefit of page specific
> > messages overriding global ones (if your implementation is clever
> > enough!) and that your global messages will be automatically supported
> > in all of Tapestry's resource handling features.
> >
> > Erik
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Passing visit variables as ognl method invocation parameters
Posted by Holger Stephan <tm...@frogleg.net>.
On Wed, 2004-09-29 at 01:42, sarah.simbad@women-at-work.org wrote:
> Me again ;-)
>
> attribute="ognl:format(key, name, numMessages)"
>
> Is it possible to pass variables as parameters using this notation?
>
> Such as:
>
> attribute="ognl:format(key, ognl:visit.userName, ognl:visit.userMessages)"
>
That'll be:
attribute="ognl:format(key, visit.userName, visit.userMessages)"
Or, if it is called in the template of a component:
attribute="ognl:format(key, page.visit.userName,
page.visit.userMessages)"
Everything is OGNL interpreted after the "ognl:".
- Holger
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Passing visit variables as ognl method invocation parameters
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
On Sep 29, 2004, at 10:42 AM, sarah.simbad@women-at-work.org wrote:
> attribute="ognl:format(key, name, numMessages)"
>
> Is it possible to pass variables as parameters using this notation?
>
> Such as:
>
> attribute="ognl:format(key, ognl:visit.userName,
> ognl:visit.userMessages)"
>
> ?
>
> Probably not, but how do you pass non-static parameters to a method
> that is directly called from the template or how do u generally access
> ognl values that are within the ognl method invocation?
You have it mostly right, and Jamie gave you the correct syntax.
attribute="ognl:format('key', visit.userName, visit.userMessages)"
I single-quoted 'key' here as it is mostly likely something static in
the template, but doesn't have to be. Your choice.
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Passing visit variables as ognl method invocation parameters
Posted by sa...@women-at-work.org.
Me again ;-)
attribute="ognl:format(key, name, numMessages)"
Is it possible to pass variables as parameters using this notation?
Such as:
attribute="ognl:format(key, ognl:visit.userName, ognl:visit.userMessages)"
?
Probably not, but how do you pass non-static parameters to a method
that is directly called from the template or how do u generally access
ognl values that are within the ognl method invocation?
:-/
________________
> It would be nice if <message-binding> (or even something like
> attribute="message:key;val1;val2") supported the parametric
> substitutions, but it does not. The only way I know of to get the
> curly bracket stuff to work would be to do this:
>
> attribute="ognl:format(key, name, numMessages)"
>
> That's not so bad, though. Look at the various signatures for format()
> for other variations. Not much different than what you were going to
> implement anyway, and you get the added benefit of page specific
> messages overriding global ones (if your implementation is clever
> enough!) and that your global messages will be automatically supported
> in all of Tapestry's resource handling features.
>
> Erik
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: ognl expressions with parameters
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
On Sep 26, 2004, at 4:48 PM, sarah.simbad@women-at-work.org wrote:
>> What is going to make it localized? Are you taking locale into
>> consideration?
> Yes.
>
>> Again, I think you should fit what you're doing into
>> the message resources extensibility - then you can simply use all the
>> usual message resource handling hooks (expr="message:key", <span
>> key="key"/>, <message-binding>).
> I dont understand what you mean by "message resources extensibility".
>
> All i could find was an IMessage interface and implementations as for
> Components, not Pages...what classes/methods do you mean so that I can
> automatically use message:key.
No offense, but I feel like we're going in circles here. I've
described the process on this list a couple of times already this past
week, but here goes again :))
Subclass BaseEngine, override getComponentMessagesSource. Create an
IComponentMessagesSource implementation (perhaps subclassing
DefaultComponentMessagesSource). Do your magic in your ICMS
implementation loading a global properties file. [Again, if you do it
generically and cleanly, please submit it to consider rolling back into
the framework].
Hook your custom engine class into .application as an engine-class
attribute.
Sounds complex, but the number of lines it took me to explain it, and
the time it has taken me to do so, is about all it would take to
implement it. Really! (in fact, I should just roll up my sleeves and
implement this particular fix since it does bug me somewhat)
> And how will it work for parameters, e.g.
>
> Welcome {1}, you have {2} new messages.
>
> ?
It would be nice if <message-binding> (or even something like
attribute="message:key;val1;val2") supported the parametric
substitutions, but it does not. The only way I know of to get the
curly bracket stuff to work would be to do this:
attribute="ognl:format(key, name, numMessages)"
That's not so bad, though. Look at the various signatures for format()
for other variations. Not much different than what you were going to
implement anyway, and you get the added benefit of page specific
messages overriding global ones (if your implementation is clever
enough!) and that your global messages will be automatically supported
in all of Tapestry's resource handling features.
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: ognl expressions with parameters
Posted by sa...@women-at-work.org.
Thanks! It was a spelling mistake. I had the ognl prefix in my original file
and I was already using:
<property name="org.apache.tapestry.default-page-class"
value="com.sandcast.examples.tapestry.CrudBasePage"/>
> What is going to make it localized? Are you taking locale into
> consideration?
Yes.
>Again, I think you should fit what you're doing into
> the message resources extensibility - then you can simply use all the
> usual message resource handling hooks (expr="message:key", <span
> key="key"/>, <message-binding>).
I dont understand what you mean by "message resources extensibility".
All i could find was an IMessage interface and implementations as for
Components, not Pages...what classes/methods do you mean so that I can
automatically use message:key.
And how will it work for parameters, e.g.
Welcome {1}, you have {2} new messages.
?
Thanks again....
> > As it should be accessible from any page template, it is located
> > within my
> > extended BasePage.
> >
> > public static String getGlobalMessage(String key);
>
> It is unnecessary to make a static method in your custom BasePage. All
> pages can be made to automatically extend from it even if you have not
> created a .java file for the pages. Put this in your .application
> file:
>
> <property name="org.apache.tapestry.default-page-class"
> value="com.sandcast.examples.tapestry.CrudBasePage"/>
>
> > <span jwcid="@Insert"
> > value="@com.sandcast.examples.tapestry.CrudBasePage@getGlobalMessage('W
> > ELCOME')"/>
> >
> > However, Tapestry will print
> > "@com.sandcast.examples.tapestry.CrudBasePage@getGlobalMessage('WELCOME
> > ')"
> > as a text on the screen instead of calling the static method from my
> > BasePage :-(
>
> The problem with what you did was not prefixing it with "ognl:" :))
>
> > How else could I access this method with parameters from HTML
> > templates?
>
> So my suggestions are implement a proper "global" message resource hook
> and/or to use the default-page-class trick to have a common base class
> other than Tapestry's BasePage.
>
> Erik
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: ognl expressions with parameters
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
On Sep 26, 2004, at 4:13 PM, sarah.simbad@women-at-work.org wrote:
> I now put a method within an own BasePage class that will
> return a localized String from a global properties file.
What is going to make it localized? Are you taking locale into
consideration? Again, I think you should fit what you're doing into
the message resources extensibility - then you can simply use all the
usual message resource handling hooks (expr="message:key", <span
key="key"/>, <message-binding>).
> As it should be accessible from any page template, it is located
> within my
> extended BasePage.
>
> public static String getGlobalMessage(String key);
It is unnecessary to make a static method in your custom BasePage. All
pages can be made to automatically extend from it even if you have not
created a .java file for the pages. Put this in your .application
file:
<property name="org.apache.tapestry.default-page-class"
value="com.sandcast.examples.tapestry.CrudBasePage"/>
> <span jwcid="@Insert"
> value="@com.sandcast.examples.tapestry.CrudBasePage@getGlobalMessage('W
> ELCOME')"/>
>
> However, Tapestry will print
> "@com.sandcast.examples.tapestry.CrudBasePage@getGlobalMessage('WELCOME
> ')"
> as a text on the screen instead of calling the static method from my
> BasePage :-(
The problem with what you did was not prefixing it with "ognl:" :))
> How else could I access this method with parameters from HTML
> templates?
So my suggestions are implement a proper "global" message resource hook
and/or to use the default-page-class trick to have a common base class
other than Tapestry's BasePage.
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
ognl expressions with parameters
Posted by sa...@women-at-work.org.
hi there!
I now put a method within an own BasePage class that will
return a localized String from a global properties file.
I already managed to use it with one method per parameter within
Home.java and using it within Home.html, e.g.:
Home.page
<span jwcid="@Insert" value="ognl:welcome"/>
and
Home.java
public String getWelcome(){
String message = getGlobalMessage("WELCOME");
return message;
}
which is stupid...i know.
I want to avoid having to write/generate 1000s of methods for every single
property. Therefore I want to call it from the html templates
with a parameter to that I only need one method.
As it should be accessible from any page template, it is located within my
extended BasePage.
public static String getGlobalMessage(String key);
<span jwcid="@Insert"
value="@com.sandcast.examples.tapestry.CrudBasePage@getGlobalMessage('WELCOME')"/>
However, Tapestry will print
"@com.sandcast.examples.tapestry.CrudBasePage@getGlobalMessage('WELCOME')"
as a text on the screen instead of calling the static method from my
BasePage :-(
How else could I access this method with parameters from HTML templates?
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Feature request: Global property files/global messages
Posted by F Da Costa <da...@xs4all.nl>.
Hi,
I'v done somethi similar to what is being discussed.
In short i'v got 1 file (yes it can become biggish) for each locale
which carries *all* the required translations,
GlobalResource_locale.properties being the basic name for locale.
these files all always stored in a dir/ package called resources.
In order to use this structure i implemented some suggestions made on
this list (thx 4 that).
I created a basic Engine class to incorporate some specific stuff i
needed in my app (actually its a core used as the center for my apps).
I have attached the (undoubtfully ugly but working ;-) ) code i
currently use.
Following the relevant methods within the classes:
StdtapestryEngine::getComponentMessagesSource() {...}
StdTapestryGlobal::getBundle(Locale locale) {...}
StdTapestryGlobal::getBundle(Locale locale, Package pack) {...}
StdTapestryGlobal::resetBundles() {...}
Undoubtfully this can be done better, smarter, faster and what have you
*but* it works *and* that is the only thing i'm concerned with. So if
this is helpfull, great. If not, great as well ;-).
My 2c.
Cheers,
Fermin DCG
sarah.simbad@women-at-work.org wrote:
> Hi again!
>
> I am using Tomcat and you can create your own web-inf directories etc.
> Never thought about the effects when it is all within a .war files.
> Thought it wouldnt matter....might be a good point though.
>
> I see what I can do...and whether I can do it after all.....
>
>
>>On Sep 26, 2004, at 10:02 AM, sarah.simbad@women-at-work.org wrote:
>>
>>>Hi Erik!
>>>
>>>What about application.properties ?
>>
>>You can (and we do have) multiple Tapestry "applications" within a
>>single web application. It needs to be application-centric even for
>>global application messages.
>>
>>
>>>I see it from this point of view:
>>>
>>>- one file is better than hundreds of files
>>>- if attributes appear on several pages, they are only listed ones,
>>>so less disk space (LOL)
>>>- but more importantly: if you need to change a word, you only
>>>need to change it at one place, without the need to touch all property
>>>files
>>>where it appears.
>>
>>No argument with any of these points. I completely agree.
>>
>>Tapestry supports what you want, but its default implementation lacks.
>>It is easy enough to customize it to what you want.
>>
>>If you patch the default message sources to support what you're after,
>>we'd certainly consider committing that to the codebase (don't forget
>>the unit tests :).
>>
>> Erik
>>
>>
>>
>>>
>>>>I agree with your sentiment, but not your implementation.
>>>>
>>>>Tapestry needs to have a global fall back for message resources, yes.
>>>>But it should be done with the same mechanism, nothing to do with
>>>>"global" at all. It would be a pretty trivial addition to Tapestry,
>>>>but not an itch I have to scratch at the moment since my custom
>>>>database loading implementation does have a global fall back if there
>>>>is no resource in the component.
>>>>
>>>>I haven't given thought to naming conventions, but I would think
>>>><application name>[_<locale>].properties would make sense and have it
>>>>live beside the .application file in WEB-INF. Whether this name needs
>>>>to be configurable is a good question (i.e. how to avoid clash with a
>>>>page or component by the same name?). If a message resource is not
>>>>found by component, it uses the global one if available.
>>>>
>>>> Erik
>>>>
>>>>
>>>>On Sep 26, 2004, at 7:08 AM, sarah.simbad@women-at-work.org wrote:
>>>>
>>>>
>>>>>Hello!
>>>>>
>>>>>What about having global property files in the next tapestry release?
>>>>>They could be all loaded in the global object and have getter Methods
>>>>>with the locale as an argument and optionally arguments to be
>>>>>included
>>>>>in a
>>>>>localized string.
>>>>>
>>>>>People could still use the page properties, but additionally, it
>>>>>would
>>>>>also be possible to work with global properties.
>>>>>
>>>>>
>>>>>Global.java
>>>>>
>>>>>public String getMessage(String key, Locale locale) {
>>>>>
>>>>> if (globalMessages == null) {
>>>>>
>>>>> this.loadMessages();
>>>>> }
>>>>>
>>>>> String localizedMessage =
>>>>>globalMessages.getProperty("welcome","locale");
>>>>> return localizedMessage;
>>>>> }
>>>>>
>>>>> public String getMessage(String key, Object[] arguments, Locale
>>>>>locale)
>>>>>{
>>>>>
>>>>> if (globalMessages == null) {
>>>>> this.loadMessages();
>>>>> }
>>>>>
>>>>> String localizedMessage =
>>>>>globalMessages.getProperty("welcome_user,
>>>>>"locale");
>>>>> localizedMessage.format(localizedMessage, arguments); // just
>>>>>as an
>>>>>example
>>>>> return localizedMessage;
>>>>> }
>>>>>
>>>>>the files could look like:
>>>>>
>>>>>global.en_UK.properties
>>>>>global.en_US.properties
>>>>>etc...
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>---------------------------------------------------------------------
>>>>>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>>>>>For additional commands, e-mail:
>>>>>tapestry-user-help@jakarta.apache.org
>>>>
>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>>>>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>>>>
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
Re: Feature request: Global property files/global messages
Posted by sa...@women-at-work.org.
Hi again!
I am using Tomcat and you can create your own web-inf directories etc.
Never thought about the effects when it is all within a .war files.
Thought it wouldnt matter....might be a good point though.
I see what I can do...and whether I can do it after all.....
> On Sep 26, 2004, at 10:02 AM, sarah.simbad@women-at-work.org wrote:
> > Hi Erik!
> >
> > What about application.properties ?
>
> You can (and we do have) multiple Tapestry "applications" within a
> single web application. It needs to be application-centric even for
> global application messages.
>
> > I see it from this point of view:
> >
> > - one file is better than hundreds of files
> > - if attributes appear on several pages, they are only listed ones,
> > so less disk space (LOL)
> > - but more importantly: if you need to change a word, you only
> > need to change it at one place, without the need to touch all property
> > files
> > where it appears.
>
> No argument with any of these points. I completely agree.
>
> Tapestry supports what you want, but its default implementation lacks.
> It is easy enough to customize it to what you want.
>
> If you patch the default message sources to support what you're after,
> we'd certainly consider committing that to the codebase (don't forget
> the unit tests :).
>
> Erik
>
>
> >
> >
> >> I agree with your sentiment, but not your implementation.
> >>
> >> Tapestry needs to have a global fall back for message resources, yes.
> >> But it should be done with the same mechanism, nothing to do with
> >> "global" at all. It would be a pretty trivial addition to Tapestry,
> >> but not an itch I have to scratch at the moment since my custom
> >> database loading implementation does have a global fall back if there
> >> is no resource in the component.
> >>
> >> I haven't given thought to naming conventions, but I would think
> >> <application name>[_<locale>].properties would make sense and have it
> >> live beside the .application file in WEB-INF. Whether this name needs
> >> to be configurable is a good question (i.e. how to avoid clash with a
> >> page or component by the same name?). If a message resource is not
> >> found by component, it uses the global one if available.
> >>
> >> Erik
> >>
> >>
> >> On Sep 26, 2004, at 7:08 AM, sarah.simbad@women-at-work.org wrote:
> >>
> >>> Hello!
> >>>
> >>> What about having global property files in the next tapestry release?
> >>> They could be all loaded in the global object and have getter Methods
> >>> with the locale as an argument and optionally arguments to be
> >>> included
> >>> in a
> >>> localized string.
> >>>
> >>> People could still use the page properties, but additionally, it
> >>> would
> >>> also be possible to work with global properties.
> >>>
> >>>
> >>> Global.java
> >>>
> >>> public String getMessage(String key, Locale locale) {
> >>>
> >>> if (globalMessages == null) {
> >>>
> >>> this.loadMessages();
> >>> }
> >>>
> >>> String localizedMessage =
> >>> globalMessages.getProperty("welcome","locale");
> >>> return localizedMessage;
> >>> }
> >>>
> >>> public String getMessage(String key, Object[] arguments, Locale
> >>> locale)
> >>> {
> >>>
> >>> if (globalMessages == null) {
> >>> this.loadMessages();
> >>> }
> >>>
> >>> String localizedMessage =
> >>> globalMessages.getProperty("welcome_user,
> >>> "locale");
> >>> localizedMessage.format(localizedMessage, arguments); // just
> >>> as an
> >>> example
> >>> return localizedMessage;
> >>> }
> >>>
> >>> the files could look like:
> >>>
> >>> global.en_UK.properties
> >>> global.en_US.properties
> >>> etc...
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> >>> For additional commands, e-mail:
> >>> tapestry-user-help@jakarta.apache.org
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> >> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Feature request: Global property files/global messages
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
On Sep 26, 2004, at 10:02 AM, sarah.simbad@women-at-work.org wrote:
> Hi Erik!
>
> What about application.properties ?
You can (and we do have) multiple Tapestry "applications" within a
single web application. It needs to be application-centric even for
global application messages.
> I see it from this point of view:
>
> - one file is better than hundreds of files
> - if attributes appear on several pages, they are only listed ones,
> so less disk space (LOL)
> - but more importantly: if you need to change a word, you only
> need to change it at one place, without the need to touch all property
> files
> where it appears.
No argument with any of these points. I completely agree.
Tapestry supports what you want, but its default implementation lacks.
It is easy enough to customize it to what you want.
If you patch the default message sources to support what you're after,
we'd certainly consider committing that to the codebase (don't forget
the unit tests :).
Erik
>
>
>> I agree with your sentiment, but not your implementation.
>>
>> Tapestry needs to have a global fall back for message resources, yes.
>> But it should be done with the same mechanism, nothing to do with
>> "global" at all. It would be a pretty trivial addition to Tapestry,
>> but not an itch I have to scratch at the moment since my custom
>> database loading implementation does have a global fall back if there
>> is no resource in the component.
>>
>> I haven't given thought to naming conventions, but I would think
>> <application name>[_<locale>].properties would make sense and have it
>> live beside the .application file in WEB-INF. Whether this name needs
>> to be configurable is a good question (i.e. how to avoid clash with a
>> page or component by the same name?). If a message resource is not
>> found by component, it uses the global one if available.
>>
>> Erik
>>
>>
>> On Sep 26, 2004, at 7:08 AM, sarah.simbad@women-at-work.org wrote:
>>
>>> Hello!
>>>
>>> What about having global property files in the next tapestry release?
>>> They could be all loaded in the global object and have getter Methods
>>> with the locale as an argument and optionally arguments to be
>>> included
>>> in a
>>> localized string.
>>>
>>> People could still use the page properties, but additionally, it
>>> would
>>> also be possible to work with global properties.
>>>
>>>
>>> Global.java
>>>
>>> public String getMessage(String key, Locale locale) {
>>>
>>> if (globalMessages == null) {
>>>
>>> this.loadMessages();
>>> }
>>>
>>> String localizedMessage =
>>> globalMessages.getProperty("welcome","locale");
>>> return localizedMessage;
>>> }
>>>
>>> public String getMessage(String key, Object[] arguments, Locale
>>> locale)
>>> {
>>>
>>> if (globalMessages == null) {
>>> this.loadMessages();
>>> }
>>>
>>> String localizedMessage =
>>> globalMessages.getProperty("welcome_user,
>>> "locale");
>>> localizedMessage.format(localizedMessage, arguments); // just
>>> as an
>>> example
>>> return localizedMessage;
>>> }
>>>
>>> the files could look like:
>>>
>>> global.en_UK.properties
>>> global.en_US.properties
>>> etc...
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail:
>>> tapestry-user-help@jakarta.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Feature request: Global property files/global messages
Posted by sa...@women-at-work.org.
Hi Erik!
What about application.properties ?
I see it from this point of view:
- one file is better than hundreds of files
- if attributes appear on several pages, they are only listed ones,
so less disk space (LOL)
- but more importantly: if you need to change a word, you only
need to change it at one place, without the need to touch all property files
where it appears.
> I agree with your sentiment, but not your implementation.
>
> Tapestry needs to have a global fall back for message resources, yes.
> But it should be done with the same mechanism, nothing to do with
> "global" at all. It would be a pretty trivial addition to Tapestry,
> but not an itch I have to scratch at the moment since my custom
> database loading implementation does have a global fall back if there
> is no resource in the component.
>
> I haven't given thought to naming conventions, but I would think
> <application name>[_<locale>].properties would make sense and have it
> live beside the .application file in WEB-INF. Whether this name needs
> to be configurable is a good question (i.e. how to avoid clash with a
> page or component by the same name?). If a message resource is not
> found by component, it uses the global one if available.
>
> Erik
>
>
> On Sep 26, 2004, at 7:08 AM, sarah.simbad@women-at-work.org wrote:
>
> > Hello!
> >
> > What about having global property files in the next tapestry release?
> > They could be all loaded in the global object and have getter Methods
> > with the locale as an argument and optionally arguments to be included
> > in a
> > localized string.
> >
> > People could still use the page properties, but additionally, it would
> > also be possible to work with global properties.
> >
> >
> > Global.java
> >
> > public String getMessage(String key, Locale locale) {
> >
> > if (globalMessages == null) {
> >
> > this.loadMessages();
> > }
> >
> > String localizedMessage =
> > globalMessages.getProperty("welcome","locale");
> > return localizedMessage;
> > }
> >
> > public String getMessage(String key, Object[] arguments, Locale
> > locale)
> > {
> >
> > if (globalMessages == null) {
> > this.loadMessages();
> > }
> >
> > String localizedMessage =
> > globalMessages.getProperty("welcome_user,
> > "locale");
> > localizedMessage.format(localizedMessage, arguments); // just
> > as an
> > example
> > return localizedMessage;
> > }
> >
> > the files could look like:
> >
> > global.en_UK.properties
> > global.en_US.properties
> > etc...
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Feature request: Global property files/global messages
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
I agree with your sentiment, but not your implementation.
Tapestry needs to have a global fall back for message resources, yes.
But it should be done with the same mechanism, nothing to do with
"global" at all. It would be a pretty trivial addition to Tapestry,
but not an itch I have to scratch at the moment since my custom
database loading implementation does have a global fall back if there
is no resource in the component.
I haven't given thought to naming conventions, but I would think
<application name>[_<locale>].properties would make sense and have it
live beside the .application file in WEB-INF. Whether this name needs
to be configurable is a good question (i.e. how to avoid clash with a
page or component by the same name?). If a message resource is not
found by component, it uses the global one if available.
Erik
On Sep 26, 2004, at 7:08 AM, sarah.simbad@women-at-work.org wrote:
> Hello!
>
> What about having global property files in the next tapestry release?
> They could be all loaded in the global object and have getter Methods
> with the locale as an argument and optionally arguments to be included
> in a
> localized string.
>
> People could still use the page properties, but additionally, it would
> also be possible to work with global properties.
>
>
> Global.java
>
> public String getMessage(String key, Locale locale) {
>
> if (globalMessages == null) {
>
> this.loadMessages();
> }
>
> String localizedMessage =
> globalMessages.getProperty("welcome","locale");
> return localizedMessage;
> }
>
> public String getMessage(String key, Object[] arguments, Locale
> locale)
> {
>
> if (globalMessages == null) {
> this.loadMessages();
> }
>
> String localizedMessage =
> globalMessages.getProperty("welcome_user,
> "locale");
> localizedMessage.format(localizedMessage, arguments); // just
> as an
> example
> return localizedMessage;
> }
>
> the files could look like:
>
> global.en_UK.properties
> global.en_US.properties
> etc...
>
>
>
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org