Re: Do wicket:message keys depend on markup hierarchy?
Hi Kaspar Replying inline.. Kaspar Fischer wrote: Thanks, Nino, for the clarifications. On 18.02.2009, at 18:10, Nino Martinez wrote: No. Just bundle the default with panel... You could create your own resource loader but seems overkill... Why do you want it working differently? I am looking for a different way because I want to make the life easier for the "users" of my components: You could consider "somediv" to be an implementation detail of the component, something that the designer of the component might want to change later on (as I did in my example). -- If he does, it will, however, require the users of the component to change their properties files. This happened to me without me realising it until a user informed me that the description of a field has suddenly changed from a very useful explanation to "Enter some text" (the default message)... You could also do it with resource models and labels.. etc the java way... Okay, I see. -- I know this issue is not so important. Still, Wicket is such a pleasure to work with as far as coding reusable components is concerned, that it would be cool to have an easy way to "export" overridable keys which relieves me from adding lots of models that clutter my code. Maybe a binding="somediv.msg"/> or an annotation? Well, just ideas... -- I guess the bottomline for me is that I should not use if I need complete freedom inside my component. I think if you just write the end of the path, like just "msg" wicket should pick that up.. But it will be overidden everywhere and not just for somediv.msg.. As I remember the override path for property files are this: Application>Page>Panel (maybe it goes deeper than panel) And as for specification I think you can do the following: For page & panels: WicketComponentPath.MesageKey (will override that message only) MesageKey (will override all messages for the page all message keys called msg If you do it in application it's just application scope, im not sure you can do panel.msg in application cant remember, but you should be able..Im not sure if this brings anything for you? Kaspar - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Do wicket:message keys depend on markup hierarchy?
Thanks, Nino, for the clarifications. On 18.02.2009, at 18:10, Nino Martinez wrote: No. Just bundle the default with panel... You could create your own resource loader but seems overkill... Why do you want it working differently? I am looking for a different way because I want to make the life easier for the "users" of my components: You could consider "somediv" to be an implementation detail of the component, something that the designer of the component might want to change later on (as I did in my example). -- If he does, it will, however, require the users of the component to change their properties files. This happened to me without me realising it until a user informed me that the description of a field has suddenly changed from a very useful explanation to "Enter some text" (the default message)... You could also do it with resource models and labels.. etc the java way... Okay, I see. -- I know this issue is not so important. Still, Wicket is such a pleasure to work with as far as coding reusable components is concerned, that it would be cool to have an easy way to "export" overridable keys which relieves me from adding lots of models that clutter my code. Maybe a binding="somediv.msg"/> or an annotation? Well, just ideas... -- I guess the bottomline for me is that I should not use if I need complete freedom inside my component. Kaspar - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Do wicket:message keys depend on markup hierarchy?
No. Just bundle the default with panel... You could create your own
resource loader but seems overkill...
Why do you want it working differently?
You could also do it with resource models and labels.. etc the java way...
Kaspar Fischer wrote:
IIUC, Wicket offers a way to "override" message keys of components.
Consider for instance a page with the following markup
with corresponding Java code
// in Page constructor
add(new MyPanel("a"));
add(new MyPanel("b"));
If MyPanel.html contains
Then I can "override" the msg in my Page.properties using
a.somediv.msg=msg a
b.somediv.msg=msg b
However, if the library designer of MyPanel changes the markup to for
instance
then I, the user of library MyPanel, am forced to change a.somediv.msg
to a.msg, etc.
Is there a way around this (without adding code for the
's)?
Kaspar
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Do wicket:message keys depend on markup hierarchy?
IIUC, Wicket offers a way to "override" message keys of components.
Consider for instance a page with the following markup
with corresponding Java code
// in Page constructor
add(new MyPanel("a"));
add(new MyPanel("b"));
If MyPanel.html contains
Then I can "override" the msg in my Page.properties using
a.somediv.msg=msg a
b.somediv.msg=msg b
However, if the library designer of MyPanel changes the markup to for
instance
then I, the user of library MyPanel, am forced to change a.somediv.msg
to a.msg, etc.
Is there a way around this (without adding code for the
's)?
Kaspar
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
