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 }
