The problem with this approach is that you are limited to a single error
message per component.
I think what we need is a label in the form component, or a resource key to
that label. The combination of this label and a resource key pointing to a
generic error message in the validator should allow us to create good error
messages.
For example if you have a text field with the label "First Name" and
max-string-length validator fails you can construct a message "First Name
contains too many characters" by using the combination of component label
and validator message "${label} contains too many characters".
Igor
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Phil Kulak
> Sent: Thursday, July 21, 2005 9:40 AM
> To: wicket-user@lists.sourceforge.net
> Subject: Re: [Wicket-user] VOTE: make AbstractValidator threadsafe
>
> How about having FormComponent supply the resource key? It
> seems like the means to uniqely identify a component (the
> resource key) belongs in the component itself, not the validator.
>
> On 7/21/05, Brad Pardee <[EMAIL PROTECTED]> wrote:
> > It seems to me you have 2 user needs here:
> >
> > 1) Those applications that follow a pretty standard
> architecture where
> > creating a Form properties file similar to the forminput
> example suits
> > their needs.
> > For these apps, sharing a static instance of a validator is
> fine and
> > results in less object creation/garbage collection.
> >
> > 2) Those applications that for whatever reason can't or
> don't want to
> > use a resourceKey generated based on the FormComponent and instead
> > want to specify their own resourceKey. For these users, it
> would be
> > easiest if they were able to set the resourceKey in the
> validator, but
> > otherwise they can get around this by extending the
> validator classes
> > or creating anonymous inner classes (provided singleton
> classes like
> > RequiredValidator change their default ctor to protected).
> >
> > Well, my application falls under #2, so you know what side I'll be
> > arguing. I think most of the validators already have
> state, be it the
> > range values for IntegerValidator or whatever. It might be argued
> > that a single static instance with this range would be
> created, but I
> > would also create a single static instance that also includes my
> > resource key. I think that in practice, the only real
> object creation
> > savings occurs when using the RequiredValidator. I think in the
> > future the plan is to allow the use of ${label}, so at that point
> > wouldn't it make sense to create a single static validator with a
> > specified resource key with value of "field '${label}' is
> required."
> > How would you achieve this without the resource key, unless
> you allow
> > wildcards in the properties file like:
> > "*.*.RequiredValidator=field '${label}' is required"
> >
> > I can see both sides, but I personally don't like the idea
> of having
> > to extend each Validator for my case.
> > I know this is a less than ideal solution, but how about if
> a ctor was
> > added that included the resourceKey and the setter was
> removed. Would
> > that make it explicit that you use the one default ctor for
> stateless
> > and the resourceKey ctor for stateful?
> >
> > Anyway, just my rambling stream of consciousness.
> > I've been using wicket for less than 2 weeks, to I may be
> completely
> > off base or missing something obvious (I think its awesome, btw).
> >
> > -Brad
> >
> >
> >
> > --- Eelco Hillenius <[EMAIL PROTECTED]>
> > wrote:
> >
> > > Chris Turner wrote:
> > >
> > > > I'm also +1 on making the current validators
> > > stateless.
> > >
> > >
> > > Ok, thanks. Jonathan also was +1 btw.
> > >
> > > > However, I think we also need to keep supporting
> > > the ability to create
> > > > stateful validators.
> > >
> > >
> > > Sure, I think that would be no problem. It is a user's
> > > responsibility now though.
> >
> >
> >
> > -------------------------------------------------------
> > SF.Net email is sponsored by: Discover Easy Linux Migration
> Strategies
> > from IBM. Find simple to follow Roadmaps, straightforward articles,
> > informative Webcasts and more! Get everything you need to get up to
> > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> > _______________________________________________
> > Wicket-user mailing list
> > Wicket-user@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wicket-user
> >
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=ick
> _______________________________________________
> Wicket-user mailing list
> Wicket-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wicket-user
>
>
>
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
