Hunsberger, Peter dijo: > Sylvain Wallez <[EMAIL PROTECTED]> 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 compatibility): fd,ft,fi I also think we can find a better names: formInclusion --> show, render, presentation, view, [fill a new name] notIncluded --> Excluded validation --> validate WDYT? Best Regards, Antonio Gallardo.
