On Fri, Feb 3, 2012 at 9:03 AM, Martin Grigorov <[email protected]> wrote:
> On Fri, Feb 3, 2012 at 6:23 PM, Igor Vaynberg <[email protected]> wrote:
>> the code is now much simpler and cleaner because years of baggage have
>> been removed. further, once we start working on clientside validation
>> extending AbstractValidator will not work because these validators
>> will have to extend Behavior instead, this commit paved the road for
>> that. also ValidationError is now much more convenient to use.
>>
>> what exactly confuses you?
>
> Here is the migration docu:
>
> Validation
> `StringValidator` will add the `maxlen` attribute if added to a
> component attached to an input tag
> martin-g: this is OK
>
> `AbstractValidator` has been removed
> martin-g: What to do now?

reintroduced

> What is #resourceKey() in 6.0 ?

this is done by overriding the decorate method mentioned later which
lets you override resource key, variables, and everything else from a
single convenient place.

> INullAcceptingBehavior doesn't have its method now. I need to make two
> classes instead of using a boolean flag as I did in 1.5.

INullAcceptingValidator never had any method. you can implement the
boolean logic yourself in your own impl. this is so rare that i dont
think it warrants a subclass of its own in the core.

> `ValidationError` now makes creating standard error keys (classname
> and classname.subtype) easier
> martin-g: this statement doesn't help at all in my migration :-)

added clarification

>
> Most validators provide a `decorate(ValidationError, Validatable)`
> method for overriding how they report errors
> martin-g: an example would be nice.

added example

-igor



>
>>
>> -igor
>>
>>
>> On Fri, Feb 3, 2012 at 2:00 AM, Martin Grigorov <[email protected]> wrote:
>>> Hi,
>>>
>>> Recently I tried to upgrade our app to Wicket 6.0 and I faced problems
>>> related to the changes in
>>> https://issues.apache.org/jira/browse/WICKET-4234.
>>> The migration page doesn't really say what to do now and I needed to
>>> browse the code in both 1.5 and 6.0 to find out how to proceed. The
>>> experience is not really pleasant.
>>>
>>> I suggest to either keep the change and improve the migration page or
>>> revert the old code.
>>> I'm more in favour of the latter because there were no complains (in
>>> tickets, in mailing list, ...).
>>>
>>> --
>>> Martin Grigorov
>>> jWeekend
>>> Training, Consulting, Development
>>> http://jWeekend.com
>
>
>
> --
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com

Reply via email to