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:25:51 GMT
Vadim Gritsenko wrote:

> 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)
> +1. I presume that it will be possible to define form-/repeater- level 
> validators in form definition file, as well as set them from Java. Am 
> I right?

By "set them from Java", do you mean setting validators for a particular 
instance of a form? What are the use cases behind this? Is it to allow 
communication between the form and the application context? If yes, what 
do you think of special "value-holder" widgets that would expose the 
communication contract between the form and the application?

>>> 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.
>>> 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.
> No objections. What about suggestion to allow nested validators?

Thinking a bit more about this, I think we must clearly define the 
semantic of nesting: obviously, if the parent validation succeeds, child 
validators are checked. But what if the parent validator fails? Does the 
form fail or do we simply ignore the child validators?

I think we're actually seeing the birth of a "if" validator that would 
allow conditional validation...

Anyway, the generalized validator will make this possible. So let's do 
it one step at a time.


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

View raw message