cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
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.
>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 Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message