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 :-)
Mmmh... IIUC, you're actually replacing group.getWidget("child-id") by ((Map)group.getValue()).get("child-id"). Does it bring some real benefits?
Anyway, having a Validator interface acting on Widget doesn't require widgets to have a value nor prohibits it.
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?
Well, september 2003 isn't that far away ;-) http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106398494806681&w=2
We were discussing the ability for event handlers to access application data. The proposals for this included adding attributes on widgets or adding hidden widgets. Rereading this, I remember that I preferred to add attributes to widgets, but no I think hidden widgets, or better specialized "app-data" widgets would better expose the communication contract between the form and the application.
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)
Actually, it does change things, since validators are no more properties of the datatype, since they apply on all widgets and not only fields. This means that <wd:validation> in fields will have to move as a sibling of <wd:datatype>.
But no fear, as we can keep the two locations for a while and deprecate the use of <wd:validation> inside <wd:datatype>.
No answer on this? If no one objects, I will implement it as I really need it now.
go ahead.
Yeah!
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects } Orixo, the opensource XML business alliance - http://www.orixo.com
