On 12/08/15 17:36, Thiago H de Paula Figueiredo wrote:
On Wed, 12 Aug 2015 11:37:29 -0300, Nathan Quirynen
<nat...@pensionarchitects.be> wrote:
Hi Thiago,
Hi!
That's actually a clever solution, but seems a bit "hacky" and I'm
not sure how it will also use the usual Index(_en).properties files?
If you create a Locale("en", "120) and a message isn't found in
Index_en_120.properties, Tapestry will try to find it in
Index_en.properties, and then in Index.properties if not found again,
just like Java resource bundles.
Oh, didn't know it worked like that! Thanks for explaining.
I solved it at the moment with adding a new binding prefix where i
pass the key and property value like following:
${messagebasedonpropertyvalue:messagekey=property}
Then in the binding implementation I get the resourcebundle based on
the property value and retrieve the message by given key.
This works as I hoped.
Yeah, adding your own bindings is a very nice feature of Tapestry. :)
I am starting to doubt that having this many properties files for
just 1 page/component is the way to go though. Maybe I'll have to
move it to the database or somewhere else.
A database is good if your messages are dynamic. If they aren't, I'd
just put them inside Index.properties or Index_en.properties, for
example, but using the property value to define the key:
hello=Hi!
hello.120=Hi, 120!
hello.130=Hi, 130!
Then @Inject Messages and use messages.get("hello." + propertyValue)
to get the message, directly in the Java class or through a custom
binding.
Yeah, they aren't really dynamic so that's why i thought they belonged
in properties files. But you are right, I can always use the property
value in the message keys if I want to keep the amount of properties
files low :)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
