Thanks for the getContainerMessages() tip. That looks like a good
solution for
getting the message propagated. I will also look into altering the
component
but I may not need flexibility to that extent.
Thanks for your help.
Liliana
On Apr 8, 2010, at 1:17 PM, Robert Zeigler wrote:
In this case, it's best to just think of a page as another
component, and the chain is currently:
component's own .properties file, app.properties file.
That is, a page only override's the messages contained in its own
catalogue. There /is/ a way to do what you want, though.
You can inject ComponentResources, and call getContainerMessages().
You can then check for the key in said messages and supply things
that way.
There are other ways of going about this, as well. Check out the
BeanEditor component for an example. It takes an "overrides"
parameter that allows you to override where messages (and property
blocks and so forth) are searched for.
Robert
On Apr 8, 2010, at 4/812:30 PM , Liliana Liu wrote:
I wanted to validate how the message override hierarchy is supposed
to work. Normally the label
specified in a page's message properties file overrides the ones
specified in app.properties.
However, that behavior does not seem to carry over when a component
is involved.
There is a component library I made where I purposely left the
labels out of the component's properties
file. I wanted the project using the component library to have the
ability to provide them since component
seem to have the highest level in the override chain. If I provide
the label in the app.properties, the
label shows up correctly as expected. But if I provide the label
in the page's properties file, it seems
the label is just ignored. Unless I am missing something, this
does not seem to work as expected?
I am using 5.1.0.5 by the way.
Thanks
Liliana
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
