sorry Sylvain this slipped my attention, haven't been deep enough into validation and event aspects to make well thought off counter proposals (not saying that they are needed, but I do understand it helps if someone at least every now and then confirms your thinking)

upfront you already have my utter trust and blessing, but lemme get into it a bit at least

Sylvain Wallez wrote:

Sylvain Wallez wrote:

Now I think that every widget should be able to have validators. Some use cases:
- on a form, to perform some inter-field validations, and even application-level validation if the means to access application data is given to the validator.
- on a repeater, to check e.g. uniqueness of some values among rows
- on a group (i.e. "class", "struct", etc) where some validation between the various widgets of the group may be wanted (actually, a form is a group)

makes sense



The current ValidationRule interface is not suited for this, as it is really tied to widgets that have a value, which neither form nor repeater have.



hm, maybe they should?
the introduction of group has got me thinking about that in fact... it would be kinda swell if group.getValue() would yield a hashMap :-)


after all the widget-instance-tree is pretty much that in some way, plus links back to their definitions and such, it's still pretty much thinking out loud, but in general something dual to the processing of requestparameters to produced some grouped value Collection seems generally usefull (but that is an academic observation since I'm not holding onto real use cases yet)

So my idea is to introduce a generalized "WidgetValidator" with a single "validate(Widget w, FormContext ctx)" method. The current ValidationRule implementations we have today can then simply become subclasses of a "FieldValidator" abstract class.

We also have to see how validators can have knowledge of the surrounding application environment to perform application-level validation. A discussion between Marc and myself a while ago came to the conclusion that we may use pseudo-fields in a form as value holders, as it would make the contract between the form and the application more visible than by adding attributes to the Form object.


ouch this is really a LONG time ago, no?


What do you think?


+1 makes sense, adds stuff without breaking things
(although it is changing some interfaces, but that is why we have this block still marked alfa after all)





No answer on this? If no one objects, I will implement it as I really need it now.


go ahead. -marc= -- Marc Portier http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center Read my weblog at http://blogs.cocoondev.org/mpo/ [EMAIL PROTECTED] [EMAIL PROTECTED]



Reply via email to