Martijn
On 10/27/05, Juergen Donnerstag <[EMAIL PROTECTED]> wrote:
Would you please open a bug for it. Thanks.
As long as long as no one else on the list is against fixing it that
way, I'll try and put it into 1.1.
Juergen
On 10/27/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> >Looks to me you are right. We didn't think about a Panel being a child
> >of a Form. I guess it was our assumption that FormComponents are
> >always a direct child of a Form.
>
> Nested panels inside the same form was the first thing I checked when evaluating Wicket. It's a very handy solution to break large forms into logical units.
>
> >I'm currently not able to look into the code. Do we traverse up the
> >component tree already, like you do?
>
> Yes, code is taken from the current ComponentStringResourceLoader (sorry, I erroneously referred to DefaultComponentStringResourceLoader). I only introduced the variable 'hierarchicalKey'.
>
> >Isn't there a risk that due to equal ids, users get messages which
> >were not meant to be for that component.
>
> Well, Wicket ensures that a path of a component is always unambiguous, so
> it works the same way as the name attributes are generated for HTML input fields.
>
> With my solution every component developer has full control over its messages in its own scope. In the following example each panel doesn't know anything about its parents, but each parent is able to override the default message of its child:
>
> - Panel1.jave has Textfield 'foo'
> - Panel1.properties contains 'foo.RequiredValidator=Foo is required'
>
> - Panel2.java uses Panel1.java as 'panel1'
> - Panel2.properties contains 'panel1.foo.RequiredValidator=Foo 1 is required'
>
> - Page3.java uses Panel2.java as 'panel2' in a form 'form'
> - Page3.properties contains 'form.panel2.panel1.foo=Regretfully Foo 1 is required'
>
> The developer of Page3 is able to override explicitly the message for 'foo' in Panel1.java.
>
> Sven
>
>
> >On 10/26/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> >> Hello,
> >>
> >> I'm struggling with the way Wicket loads String resources, particularly how
> >DefaultComponentStringResourceLoader loads validation messages.
> >>
> >> Let's say that we have the following component hierarchy:
> >> APage
> >> ->BForm id="b"
> >> -->XPanel id="x"
> >> ---->RequiredTextField id="foo"
> >> -->YPanel id="y"
> >> ---->RequiredTextField id="foo"
> >>
> >> XPanel knows nothing about its containing form or page, nevertheless
> >XPanel's validation keys must be prefexed with the form's id:
> >>
> >> XPanel.properties :
> >> b.foo.RequiredValidator = Foo is required.
> >>
> >> IMHO this introduces an unwanted dependency of XPanel on its parental form
> >(i.e. id="b").
> >>
> >> Furthermore there is no way to override the foo messages separately for
> >XPanel and YPanel:
> >>
> >> APage.properties:
> >> b.foo.RequiredValidator = Foo is required in x ??
> >> b.foo.RequiredValidator = Foo is required in y ??
> >>
> >> Now I would prefer, that the validation text for XPanel's foo would be
> >searched like in the following:
> >>
> >> APage.properties:
> >> b.x.foo.RequiredValidator = Foo is extremely required.
> >> XPanel.properties:
> >> foo.RequiredValidator = Foo is required.
> >>
> >> YPanel's validation text could stay unaltered:
> >>
> >> YPanel.properties:
> >> foo.RequiredValidator = Foo is required.
> >>
> >> Fortunately Wicket is pluggable enough to set this straight:
> >> I've written my own ValidatorResourceKeyFactory, that omits the form's id
> >from the key:
> >>
> >> public String newKey(IValidator validator, FormComponent component)
> >> {
> >> return component.getId() + "." + Classes.name(validator.getClass());
> >> }
> >>
> >> With a custom ComponentStringResourceLoader the key to lookup a message is
> >always prefixed with the ids of the parental components:
> >>
> >> // Build search stack
> >> Stack searchStack = new Stack();
> >> searchStack.push(component);
> >>
> >> String hierarchicalKey = key;
> >> if (!(component instanceof Page))
> >> {
> >> MarkupContainer c = component.getParent();
> >> while (true)
> >> {
> >> searchStack.push(c);
> >> if (c instanceof Page)
> >> break;
> >> hierarchicalKey = c.getId() + "." + hierarchicalKey;
> >> c = c.getParent();
> >> }
> >> }
> >>
> >> // Iterate through search stack
> >> String value = null;
> >> while (!searchStack.isEmpty())
> >> {
> >> Component c = (Component)searchStack.pop();
> >> Class cc = c.getClass();
> >>
> >> while ( value == null ) {
> >> // Locate previously loaded resources from the cache
> >> final String id = createCacheId(cc, style, locale);
> >> ValueMap strings = (ValueMap)resourceCache.get(id);
> >> if (strings == null)
> >> {
> >> // No resources previously loaded, attempt to load them
> >> strings = loadResources(c, cc, style, locale, id);
> >> }
> >>
> >> // Lookup value
> >> value = strings.getString(hierarchicalKey);
> >> if (value != null)
> >> break;
> >>
> >> // Move to next superclass
> >> cc = cc.getSuperclass();
> >> if (isStopResourceSearch(cc)) break;
> >> }
> >> if (value != null) {
> >> break;
> >> } else {
> >> hierarchicalKey =
> >hierarchicalKey.substring(hierarchicalKey.indexOf ('.') + 1);
> >> }
> >> }
> >>
> >> // Return the resource value (may be null if resource was not found)
> >> return value;
> >>
> >> Works great :).
> >>
> >> Now I really wonder who would want to use the
> >DefaultComponentStringResourceLoader at all? I don't think that its way of
> >loading resources is useful, since it will introduce dependencies and sooner
> >or later you'll run into name clashes. IMHO this severely hinders reuse of
> >components inside of forms.
> >>
> >> Note that my solution also works nicely with localization of other
> >components, e.g. the RadioChoice (line 393).
> >>
> >> Thanks
> >>
> >> Sven
> >>
> >>
> >> -------------------------------------------------------
> >> This SF.Net email is sponsored by the JBoss Inc.
> >> Get Certified Today * Register for a JBoss Training Course
> >> Free Certification Exam for All Training Attendees Through End of 2005
> >> Visit http://www.jboss.com/services/certification for more information
> >> _______________________________________________
> >> Wicket-user mailing list
> >> [email protected]
> >> https://lists.sourceforge.net/lists/listinfo/wicket-user
> >>
> >
> >
> >-------------------------------------------------------
> >This SF.Net email is sponsored by the JBoss Inc.
> >Get Certified Today * Register for a JBoss Training Course
> >Free Certification Exam for All Training Attendees Through End of 2005
> >Visit http://www.jboss.com/services/certification for more information
> >_______________________________________________
> >Wicket-user mailing list
> >[email protected]
> > https://lists.sourceforge.net/lists/listinfo/wicket-user
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the JBoss Inc.
> Get Certified Today * Register for a JBoss Training Course
> Free Certification Exam for All Training Attendees Through End of 2005
> Visit http://www.jboss.com/services/certification for more information
> _______________________________________________
> Wicket-user mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/wicket-user
>
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
