cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [IMP] Re: Generalizing validation to non-valued widgets (was Re: [cforms] Optionally required fields)
Date Sun, 11 Jan 2004 10:15:38 GMT
Marc Portier wrote:

> 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 ;-)

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.



Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -

View raw message