Re: Widget states: let's do it (was Re: CForms making widgets invisible)

[Antonio Gallardo <ag...@agssa.net>]

Sylvain Wallez dijo:
> Antonio Gallardo wrote:
>
>>Hunsberger, Peter dijo:
>>
>>
>>>Sylvain Wallez <sy...@apache.org> 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...

Hi:

I was thinking for a while about
http://cocoon.apache.org/2.1/userdocs/forms/widget_field.html ... and my
initial conclusion is:

We don't need the new attributes

I will try explain why:

1. new @validation:

We already have @required and on the above document we states:
<snip>
The required attribute is optional, by default it is false. It indicates
whether this field is required. This is a static property of the widget.
If you want the field to be "conditionally required", then set this to
false and use custom validation logic to check the requiredness of the
field.
</snip>

I think we can build the form definition using a dynamic pipeline to
switch on or off this @attribute and the correspondent validation. We
already do that in some forms.

2- new @formInclusion = [normal | disabled | hidden | notIncluded])

The CForm primary rendering is XML. If in the cocoon samples we transform
the CForms to HTML, this is just a "casuality". I hope you get the idea in
the good sense. :-D

So, in this case we can transform any field to be hidden or whatever we want.

In fact, we are free to change the last used XSLT stylesheet that is used
for the final step (XML -> HTML) how we want. We can decide in this level
how the final field will be rendered: hidden, active, noIncluded, etc.
We can also do in the styesheet not normal behavior as:

Transform a text field --> a radio button, etc.

I expect you get the idea.....

Of course often we tend to think that the XSLT stylesheets already
distributed in cocoon are the once we need to use and there need to
address each posible use-case and this is why we try add on there new
attributes, while in fact this is not the case.

BTW, I don't see the need to send hidden params. On the serverside we
already have a full form model with current values. Why to send hidden
parameters to get them back with the same value? (Assuming there are no
hand crafted uri's). It is only a waste of bandwidth + other issues. . Or
am I wrong?

Note: I am not against to enhance the CForms interface. If we want a truly
nice form specification, we need very carefully think each step we do with
the interface: adding or removing attributed is very important, because
even in the case we do a bad move, we will need to support it over and
over. And we know that keep backward compatibility os not so easy. ;-)

As usual, comments are very welcome. ;-)

Best Regards,

Antonio Gallardo