yes, that is a bug
Juergen
On 11/8/05, Ingram Chen <[EMAIL PROTECTED]> wrote:
> I check out latest CVS HEAD, but find strange behavior:
>
> If a MyPage.properties as below:
>
> RequiredValidator = ${label} is required
> myForm.bookId = Book ID
>
> then validation message work well and is "Book ID
It works on my side. I created unit tests and I think they are ok. I
enabled logging for the package and it doesn't happen. I tested the
formInput example and it works without changes. Did you update
AbstractValidator as well?
Juergen
On 11/7/05, Sven Meier <[EMAIL PROTECTED]> wrote:
> Hello Juer
Hello Juergen,
maybe it shouldn't - but currently it does ;).
I debugged the new algorithm of ComponentStringResourceLoader today. As
I already suspected, the id of the validated component is duplicated in
the prefixKey, since both DefaultValidatorResourceKeyFactory and
ComponentStringResour
It shouldn't. I guess the important point is that
ComponentStringResourceLoade does not get the FormComponent (text1)
You don't start looking for text1 in the formComponents properties
file, do you? You start with the parent component containing text1. A
key text1 expresses that text1 is a child of
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());
}
ComponentStringResourceLo
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"
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
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:
> >
> >
+1, if it doesn't break stuff.
MartijnOn 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 thatway, I'll try and put it into 1.1.JuergenOn 10/27/05,
[EMAIL PROTECTED] <[EMAIL PROTECTED
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
>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
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.
I'm currently not able to look into the code. Do we traverse up the
component tree already, like you do? Isn't there a risk that
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
13 matches
Mail list logo
