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
