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