cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Antonio Gallardo" <>
Subject RE: Widget states: let's do it (was Re: CForms making widgets invisible)
Date Thu, 23 Sep 2004 20:02:11 GMT
Hunsberger, Peter dijo:
> Sylvain Wallez <> writes:
>> Yes, that a problem we already have to face today if e.g. a required
>> widget is not present in the form template.

I think this is an application bug an we cannot take care of that in the
definition. ;-) See below....

>> Some ideas about this problem?
> Yes; why would you ever do validation on a field that the user cannot
> change?
> If a field is hidden but not included on the form the user cannot
> (normally) change it.  If there is some JavaScript that updates it, it
> is up to the developer to make sure that only valid values come back.
> (Hand crafted POSTS are not something that can be solved by validation
> so forget about them for the moment.)  IOW, the only time you do
> validation is if the values that can be returned by the widget can be
> entered by the end user.
> A side comment is that much of this sounds like a mixing of concerns.
> Presentation and validation should pretty much be separated, use two
> different flags if you want to allow for turning validation off and on
> and don't mix it with the presentation state.
> 	formInclusion = normal | disabled | hidden | notIncluded
> 	validation = true | false
> Where validation defaults to false if formInclusion is not normal. (And
> here I use hidden because it means exactly what you would expect as a
> normal HTML author...)

I like this new attributes. Another thing to be done is discuss where we
will include this (I expect optionals atrributes - to not break


I also think we can find a better names:

formInclusion --> show, render, presentation, view, [fill a new name]
notIncluded -->  Excluded
validation --> validate


Best Regards,

Antonio Gallardo.

View raw message