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.
I think we have enough votes. I've committed the change.
Regards,
Eelco
A particular use case for this is that that validation rules may be
different for each user, for example:
I want to build a password validator. However, the rules as to what
makes a valid password are different dependent on what back-end
systems a user can access (e.g. high security passwords for critical
systems, lower security for customer documentation access). I
therefore need to, at the time the password change form is created,
determine what password rules I wish to apply (may involve expensive
database access) and then create a validator instance for that form
containing the rules that I determined. Obviously I could encode all
these rules into my business logic and models, but I would rather do
it at the web layer for efficiency and consistent error feedback
purposes.
regards,
Chris
Martijn Dashorst wrote:
I think the Singleton approach for the validators is a correct
design. Validators would otherwise be created a lot of times (for
each field a multiple), so this will keep our memory usage and GC
time down.
As such we must make sure we don't introduce any kind of state into
the validators. Especially when the first goal was to make them
threadsafe by removing state, we shouldn't introduce state again.
-1 on the introduction of the stateful resourcekey. +1 on the
stateless validators.
Martijn
Johan Compagner wrote:
yes this looks fine to me.
then they can take it from the given component or give something else.
Eelco Hillenius wrote:
I guess resourceKey isn't such a good idea after all, as it breaks
the thread safety we just introduced. It should be enough to remove
this but make getResourceKey(FormComponent) overridable, so people
can do this with annonymous classes. Slightly inconvient, but safe.
And safe should win over inconvient.
Eelco
Eelco Hillenius wrote:
Yes, but it is optional. So, if people don't use the resourceKey,
the validators hold no state. If they do, it holds state, which
/could/ lead to non-thread safe behaviour. My guess was that that
would be clear enough? Maybe we should get rid of the singleton
required validator just to be sure... cheap enough to create such
objects anyway.
Eelco
Johan Compagner wrote:
is the resourcekey for such a validator always the same?
Because now you have extracted out the formcomponent but
introduced the resourcekey.as a variable
-------------------------------------------------------
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_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_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_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_id=7477&alloc_id=16492&op=click
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
