Who is for this? It would mean breaking a lot of clients (dangerous break too, as it means changing overridable methods), and imho it would make the validators look a bit more ugly (every method has to be extended with a FormComponent argument). __________________________________________ It maybe is 'ugly' to carry the parameter around, but there current version is a lot uglier. The code is complicated to understand and it locks the complete system. So if there are a lot of users that use the validator.. the single instance (Validators ca be singletons) has to be locked by each client multiple times. And offcource.. there are a lot of methods that don`t make sense and have vague concurrency semantics. I would call the removal of the locking and better concurrency semantics a big improvement. It would however make AbstractValidator thread safe, and it makes implementing IValidator from scratch maybe a bit easier (IValidator has to change too for this change to work). ______________________________________________ The IValidator doesn`t have to change. The interface remains the same, only the documentation of 'needs to be synchronized' has to be removed. Btw I`m not going to use the current validators anyway. I`m developing a set of Validators that are more consistent and easier to use. Maybe my company is going to make it opensource so everyone can use them.
I'm +0 ---------------------------------------------------- I`m +100 *hopes nobody has the idea to vote against with a bigger number* Eelco ------------------------------------------------------- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-user
<<winmail.dat>>
