cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hunsberger, Peter" <Peter.Hunsber...@STJUDE.ORG>
Subject RE: Widget states: let's do it (was Re: CForms making widgets invisible)
Date Thu, 23 Sep 2004 13:33:23 GMT
Sylvain Wallez <> writes:

<snip>discussion about widgets</snip>

> >> Interesting thoughts. But as we saw previously, "hidden" has an
> >> implied meaning because of its use for <input 
> type="hidden"> in HTML 
> >> and I'd like to avoid it.
> >>
> >> What you're describing here is a widget state that is even less
> >> visible than invisible, since no validation occurs. What about a 
> >> "phantom" state, where the widget exists but isn't validated?
> >>
> >> BTW, overnight I finally felt that "enabled" being the negation of
> >> "disabled" can lead to confusion as when we have to talk about a 
> >> widget that's not in "enable" state, the natural word that 
> comes is 
> >> "disabled" which is only one of the particular possible 
> states for a 
> >> non-enabled widget. So in the end, I think "active" is better than 
> >> "enabled".
> >>
> >> That would lead to:
> >>  active (default) < disabled < invisible < phantom
> >>
> >> Thoughts?
> >>
> >> Sylvain
> >>
> > Ok sounds good to me
> >
> > What would happen when an invisible field doesn't pass 
> validation and
> > the enduser of a running system doesn't know that he's made 
> a mistake 
> > entering data.
> > The point I'm trying to make is that informing endusers about 
> > validation errors could be a tricky issue becausae a user 
> can't enter 
> > data into fields he cannot see and would be a burden for system 
> > developers because they have to test forms throughly to 
> avoid confusion
> Yes, that a problem we already have to face today if e.g. a required 
> widget is not present in the form template.
> Some ideas about this problem?

Yes; why would you ever do validation on a field that the user cannot

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...)


View raw message