Hello Juergen,
I've taken a short look on your code in the CVS :
DefaultValidatorResourceKeyFactory.java:
* public* String newKey(IValidator validator, FormComponent formComponent)
{
* return* formComponent.getId() + *"."* + Classes.name(validator.getClass());
}
ComponentStringResourceLoader.java:
...
/// Build search stack
/ Stack searchStack = *new* Stack();
searchStack.push(component);
String prefixKey = component.getId() + *"."* + key;
I'm wondering if this leads to a duplicated ID of the validated
component in prefixId? e.g.
form1.text1.text1.RequiredValidator
But maybe I'm wrong - so I'll better give it a try on Monday.
Thanks
Sven
Juergen Donnerstag wrote:
Repetition: Message retrieval for the following scenario -
form->panel->textfield - is currently not supported
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"
Sven made a suggestion on how to change which is not 100% compliant. I
worked a bit on it and I think I found a solution. An example:
The Page looks like
add(new Label("label"));
Form form1 = new Form("form1");
add(form1);
form1.add(new MyTextField("text1", "input-1"));
form1.add(new MyTextField("text2", "input-2"));
Form form2 = new Form("form2");
add(form2);
Panel panel1 = new Panel("panel1");
form2.add(panel1);
panel1.add(new MyTextField("text3", "input-3"));
panel1.add(new MyTextField("text4", "input-4"));
Panel panel2 = new Panel("panel2");
form2.add(panel2);
panel2.add(new MyTextField("text5", "input-5"));
panel2.add(new MyTextField("text6", "input-6"));
And the properties file:
# Default message
RequiredValidator = Default message: ${label} required
# A Textfield with label
form1.text1 = text1label
form1.text1.RequiredValidator = ${label} is required
# A TextField without label. label should default to the formComponent's id
form1.text2.RequiredValidator = ${label} is required
# This one is wrong. Because the panel id is missing
form2.text3.RequiredValidator = wrong: text3333 is missing
# Must be like
form2.panel1.text3.RequiredValidator = ok: text3333 is missing
form2.panel1.text4 = Text4Label
form2.panel1.text4.RequiredValidator = ok: ${label} is missing
form2.panel2.text5.RequiredValidator = ok: text555 is missing
#form2.panel2.text6.RequiredValidator = ok: text555 is missing
form2.text5.RequiredValidator = wrong: text555 is missing
form2.text6.RequiredValidator = wrong: text555 is missing
form2.panel1.text5.RequiredValidator = wrong: text555 is missing
form2.panel1.text6.RequiredValidator = wrong: text555 is missing
I think it is 100% compliant now, solves the panel problem and as
suggested by Sven adds one more (IMO useful) feature; useful for
self-contained, re-usable components. The key (e.g.
text6.RequiredValidator) is prepended with the relativ path (virtual
root component is the component associated with the properties files).
His english is better than mine and his examples probably as well.
I'll check it in tonight.
Juergen
On 10/29/05, Sven Meier <[EMAIL PROTECTED]> wrote:
I've opened a bug, see:
http://sourceforge.net/tracker/index.php?func=detail&aid=1339904&group_id=119783&atid=684975
Sven
Juergen Donnerstag wrote:
Did you open a bug or RFE already? If not, please do so, otherwise
there is always a risk that it'll be forgotten.
Juergen
On 10/27/05, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
+1, if it doesn't break stuff.
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
Wicket-user@lists.sourceforge.net
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
Wicket-user@lists.sourceforge.net
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
Wicket-user@lists.sourceforge.net
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
Wicket-user@lists.sourceforge.net
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
Wicket-user@lists.sourceforge.net
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
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user