cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Re: [cforms] enabling all widgets to listen to value changed events
Date Wed, 14 Jul 2004 21:28:02 GMT
Tim Larson wrote:

>On Wed, Jul 14, 2004 at 12:41:36PM +0000, Joerg Heinicke wrote:
>  
>
>>I have a form where for legal and natural persons different widgets have to be
>>presented. I implemented it using a union widget and storing the persontype on a
>>field with datatype ineger, the value is bound to a bean. To make this value
>>usable in the union's case widget it must be transformed into a string. So my
>>form definition looks like the following:
>>    
>>
>
>Btw, Do you have ideas on how we should lift the "string" type restriction?
>
><snip sample/> 
>  
>
>>I wonder why we do not enable all widgets to listen to value changed events.
>>Though the user can not fire the event, it can happen programmatically like in
>>my use case above. Besides this one (which is more a work around of the union
>>widget's restriction) there are also other use cases imaginable, e.g. in a
>>simple game: one widget is "number of trial", another one is "trials left". The
>>second one is only updated if the first one has changed - of course the user
>>must not update them by hand, so they are output widgets.
>>
>>WDYT?
>>    
>>
>
>Yes, let's fix that,
>

+1 all widgets that have a value should be change-listener-aware.

>and while we are at it, I would also like widgets to have
>these dynamically selectable options:
>
>  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.)
>  
>

I'm not sure about this one, as a password input seems to me to have a 
different behaviour than the regular field: it should display some data, 
simply to have "*****" in the input, but consider the input value only 
if it's different from the one that was sent. And this cannot be 
achieved by simply having a writeonly state.

>    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.)
>
>  Via the model and/or the view (not secure, relies on well-behaved clients)
>    Inline - displayed but not in an input box (like an "output" widget.)
>    Enabled - displayed in an editable input box (like a "field" widget.)
>    Disabled - displayed in a non-editable input box.
>    Hidden - not-displayed, hidden input box.
>  
>

This can be secure if we allow the view to set that state on the 
widgets. That way, the widgets know how they were displayed when the 
request is submitted.

>  Default mapping from model to view (can be overriden by the view):
>    Read/write - Enabled
>    Readonly - Inline
>    Writeonly - Enabled
>    Neither - Output to view suppressed
>  
>

I don't thing there should be a relation to the mapping as we may well 
have "neither" fields that need to be bound.

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }


Mime
View raw message