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=click
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
