Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <4151DD04.8070607@reverycodes.com>
Date: Wed, 22 Sep 2004 16:13:56 -0400
From: Vadim Gritsenko <vadim@reverycodes.com>
User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: Widget states: let's do it (was Re: CForms making widgets
 invisible)
References: <41514D5B.20709@juwimm.com> <415186AA.50601@apache.org>
 <415195F7.3010805@reverycodes.com> <4151A003.1080004@apache.org>
 <4151CA86.8040400@reverycodes.com> <4151DAAE.1040408@apache.org>
In-Reply-To: <4151DAAE.1040408@apache.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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. In this case, I'm +1, as long as 
styling concern is kept separate :)

Vadim