cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruno Dumon <br...@outerthought.org>
Subject Re: CForms validator function Re: cvs commit: cocoon-2.1/src/blocks/forms/samples/forms sitemap.xmap customvalidationdemo_form.xml customvalidationdemo_template.xml
Date Thu, 06 May 2004 21:34:51 GMT
On Thu, 2004-05-06 at 19:15, Sylvain Wallez wrote:
> Bruno Dumon wrote:
> 
> >On Thu, 2004-05-06 at 16:23, vgritsenko@apache.org wrote:
> >  
> >
> >>vgritsenko    2004/05/06 07:23:04
> >>
> >>  Modified:    .        status.xml
> >>               src/blocks/forms/samples sitemap.xmap welcome.xml
> >>               src/blocks/forms/java/org/apache/cocoon/forms/flow/javascript
> >>                        Form.js
> >>               src/blocks/forms/java/org/apache/cocoon/forms/flow/javascript/v2
> >>                        Form.js
> >>               src/blocks/forms/java/org/apache/cocoon/forms/flow/javascript/v3
> >>                        Form.js
> >>               src/blocks/forms/samples/forms sitemap.xmap
> >>  Removed:     src/blocks/forms/samples/flow customvalidationdemo.js
> >>               src/blocks/forms/samples/forms customvalidationdemo_form.xml
> >>                        customvalidationdemo_template.xml
> >>  Log:
> >>  Remove flow level custom validators
> >>  http://marc.theaimsgroup.com/?t=108091920700001&r=1&w=2
> >>  
> >>    
> >>
> >
> >(I highly appreciate the cleanup work, but...)
> >
> >Allthough the flow-level validator function was a hack, won't it be too
> >annoying for users who are relying on it to throw it out completely?
> >This will make the woody -> cforms move a bit harder...
> >  
> >
> 
> Cleaning up means so backwards incompatibilities, and I'm +1000 to 
> remove this hack. What we can do however, is check if a "validator" 
> property exists in a form object and fail hard with an exception if it 
> exists. That way, users will be informed that this "feature" has been 
> removed.

ok, sounds good.

> 
> >Also, couldn't the example be updated to how it should be done now?

aha, Sylvain mentions another sample of custom validation below so that
should be fine.

> >
> >Lastly, the behaviour of the WidgetValidators are not yet a complete
> >replacement for the validator function, see this important BUT in
> >AbstractContainerWidget:
> >
> >    public boolean validate() {
> >        // Validate self only if child widgets are valid
> >        //TODO: check if we should not change this to still validating
> >kids first 
> >        // BUT also validating the top level
> >        if (widgets.validate()) {
> >            return super.validate();
> >        } else {
> >            return false;
> >        }
> >    }
> >
> >Is there anyone who knows a reason why the parent shouldn't be validated
> >if kids fail? Seems to be too limitting to me.
> >  
> >
> 
> Ditto. A validator relying on other widget's values (be them children or 
> not) must be consider these widgets do be potentially invalid. And there 
> are some valid use cases in our "form1" sample: the "contacts" repeater 
> checks uniqueness of contact names among rows, and this validation makes 
> sense even if emails are invalid.

yep. Would be nice if this change could still make it before the code
freeze (I probably won't have time).

-- 
Bruno Dumon                             http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org                          bruno@apache.org


Mime
View raw message