cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: Widget states: let's do it (was Re: CForms making widgets invisible)
Date Wed, 22 Sep 2004 21:17:06 GMT
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:
>>> 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 Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message