Sylvain Wallez schrieb:
I don't think that having a separate validation state is a good idea, I also think that all widgets should be validated when data is entered or changed. By doing this no phantom state would be necessary because nobody can enter data into an invisible field and when no data is entered nothing would be there to be validated, so an invisible state would be sufficient.Antonio Gallardo wrote:
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
Ok, maybe the "phantom" state isn't a good idea after all. But I still consider that "hidden" is a view concern since it has no impact on the request processing.
Now I have a problem with separating state and validation: what does it mean if an active widget has validate="false". Does it mean that we allow the user to validate a form where she has input invalid data? Doesn't seem good to me...
Sylvain
Using that apprioach the main problem in my opinion is the "required" flag. What would happen if a required widget is invisible an no data is entered ? (There certainly wouldn't be any validation going on when no data was prevoisly entered) I guess there has to be a distinction between validation and checking wether a widget is required or not.
By the way why do we need better names I think when using active, disabled, invisible for widget states it is pretty clear what's meant, but I guess thats just another personal opinion.
The main thing is that whatever the state is called it should be pretty self-explanatory or endusers will get confused.
Claudius
