You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@wicket.apache.org by Martijn Dashorst <ma...@gmail.com> on 2007/10/25 22:07:05 UTC

On resource bundles and component path's

Say I have a page and a panel. The panel contains wicket:message's
with keys 'foo1', 'foo2' and 'foo3'.

<!-- Panel.html -->
<html><body><wicket:panel>
<table>
<tr><td>Foo1</td><td><wicket:message key="foo1"></wicket:message></td></tr>
<tr><td>Foo2</td><td><wicket:message key="foo2"></wicket:message></td></tr>
<tr><td>Foo3</td><td><wicket:message key="foo3"></wicket:message></td></tr>
</table>
</wicket:panel></body></html>

The page contains the panel with ID 'panel'.

# Panel.properties
foo3=Foo3 from panel.properties

# Page.properties
panel.foo1=panel.foo1 from page.properties
panel.foo2=panel.foo2 from page.properties
foo2=foo2 from page.properties
foo3=foo3 from page.properties

What will be the expected outcome of this table? I would figure the following:

<table>
<tr><td>Foo1</td><td>panel.foo1 from page.properties</td></tr>
<tr><td>Foo2</td><td>panel.foo2 from page.properties</td></tr>
<tr><td>Foo3</td><td>Foo3 from panel.properties</td></tr>
</table>

However it renders (1.3-beta3):
<table>
<tr><td>Foo1</td><td></td></tr>
<tr><td>Foo2</td><td>foo2 from page.properties</td></tr>
<tr><td>Foo3</td><td>Foo3 from panel.properties</td></tr>
</table>

Am I thinking wrong here?

Martijn

-- 
Buy Wicket in Action: http://manning.com/dashorst
Apache Wicket 1.3.0-beta4 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta4/

Re: On resource bundles and component path's

Posted by Christian Oldiges <no...@oldiges.com>.

Martijn Dashorst wrote:
> 
> # Panel.properties
> foo3=Foo3 from panel.properties
> 
> # Page.properties
> panel.foo1=panel.foo1 from page.properties
> panel.foo2=panel.foo2 from page.properties
> foo2=foo2 from page.properties
> foo3=foo3 from page.properties
> 

Juergen Donnerstag wrote:
> 
> I would have expected
> 
> <table>
> <tr><td>Foo1</td><td>panel.foo1 from page.properties</td></tr>
> <tr><td>Foo2</td><td>panel.foo2 from page.properties</td></tr>
> <tr><td>Foo3</td><td>foo3 from page.properties</td></tr>
> </table>
> 
> a) panel.fooX is more specific than fooX and should take precendence
> b) assume you purchase (no source code) a ready made set of wicket
> components with pre-configured properties which you can not change.
> But since it is a component you will add it to a page, panel whatever.
> Hence adding a property to page should overwrite what is
> pre-configured by the vendor. Which however is a little bit dangerous
> since if you add another component with the same id to the page (no
> path), they may end up using the same property.
> 

I agree with a) but think for foo3 the more local string in panel.properties
should take precedence over the more general one defined in page.properties.
If one wants to override a string defined in a subcomponent's resource file,
the notation using the component id as a prefix is sufficient and very clear
to the reader but currently there is no way to NOT override a subcomponent
if the parent uses the same key for some reason.

Example:

I have many panels and ALL of them define a "title" in their own properties
files. Now I want to create a more complex panel of some of the smaller
ones. To stick to my rule of defining a title property for each panel, the
complex panel's title overrides the titles of the subpanels.

complexpanel.properties:
title=Complex Title

panel1.properties:
title=Panel 1 Title

panel2.properties:
title=Panel 2 Title

If complexpanel contains panel1 and panel2 they both display "Complex Title"
as their title.
Looking at the Javadoc of ComponentStringResourceLoader, this seems to be
intentional but I think the behaviour is not the optimal solution.
Overriding is still possible using e.g. "panel1.title" in
complexpanel.properties, but NOT overriding is not possible.

Suggestion:

Add a setting which might default to the current behaviour that allows to
turn off the lookup of the non-prefixed key in the parents resource files.

ComponentStringResourceLoader.loadStringResource(final Component component,
final String key)

would need to check this settings flag:

			// If not found, than check if a property with the 'key' provided by
			// the user can be found.
			if (string == null)   &&   CHECK SETTING HERE
			{
				string = loadStringResource(clazz, key, locale, style);
			}

What do you think?
-- 
View this message in context: http://www.nabble.com/On-resource-bundles-and-component-path%27s-tf4693318.html#a13451135
Sent from the Wicket - Dev mailing list archive at Nabble.com.

Re: On resource bundles and component path's

Posted by Martijn Dashorst <ma...@gmail.com>.

I'll take a quick look (it's in my best interest too)

Martijn

On 11/5/07, Eelco Hillenius <ee...@gmail.com> wrote:
> On 11/4/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > On 10/28/07, Martijn Dashorst <ma...@gmail.com> wrote:
> > > Makes sense. And I see it works now perfectly. Thanks!
> >
> > Actually, it doesn't seem to work for me.
> >
> > I have DiscountsPage and UserPanel. The UserPanel is added to the page
> > with id 'userPanel'. The user panel has <wicket:message
> > key="signed_in_as">
> >
> > Matching signed_in_as in UserPanel.properties works, signed_in_as in
> > DiscountPage.properties matches but userPanel.signed_in_as in
> > DiscountsPage.properties does not.
> >
> > Anyone know why? The source is at
> > http://wicketinaction.googlecode.com/svn/trunk/book-wicket-in-action,
> > package wicket.in.action.chapter13.locdiscounts
>
> Sorry for pushing this. But if anyone with a little bit of time to
> spare could help me out, I could finally finish that friggin' chapter
> I'm working on. Basically, I want to know whether this is a bug I'm
> experiencing (possibly in my code), or whether I'm making the wrong
> assumption.
>
> Eelco
>


-- 
Buy Wicket in Action: http://manning.com/dashorst
Apache Wicket 1.3.0-beta4 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta4/