Vadim Gritsenko wrote:
Sylvain Wallez wrote:
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
And now, with "enabled"/"disabled"/"invisible"?
I guess I'm Ok with that; can you also comment how it relates to: http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=108981424626685
Your proposal seems to differ a bit by mixing presentation and input/output concern - I guess there is a reason for this too :)
My proposal is only about what data comes in a out from the form model. The state certainly impacts how it is displayed, but this can be further refined in the view. For example Tim's "inline" and "disabled" proposal are two possible stylings of a disabled widget, in the same manner than an enabled widget that can have the "hidden" styling.
So it is almost as it was described in mentioned email:
Via the model (secure, does not rely on well-behaved clients)
Read/write - Like a normal widget
Readonly - Like an output widget.
Writeonly - For sensitive input (e.g. passwords not echoed to the client.)
Neither - For server-side data (e.g. to still allow use of the other
benefits of cforms widgets, such as validation, value-changed-events,
and the ability to load and save via bindings.)
With the exception of Writeonly.
Exactly. As as stated previously, wite only seems to me a very specific case that should be handled by a special fd:passwordfield widget, just like we have fd:booleanfield.
In this case, I'm +1, as long as styling concern is kept separate :)
Kewl :-)
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
