cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Larson <...@keow.org>
Subject Re: disabling widgets
Date Mon, 05 Apr 2004 15:37:42 GMT
On Mon, Apr 05, 2004 at 01:28:42PM +0200, Sylvain Wallez wrote:
> So, I propose the following changes to Cocoon forms:
> - add a state to widgets (enabled/disabled/hidden).
> - move to a generator approach.

No official comment on the generator approach since I have not
yet tried it, but it looks pretty good from the descriptions I
have seen.  I was just getting ready to make a proposal about
widget states, so I will just copy it below:

Remember the "direction" attribute in the binding?  I think we
need something like that here, but with a different name that
fits this context.  Here are the options I propose for this attr:

  (Note: Not proposing names, just listing the semantics we need.)

  both
      Send value and receive value from user
      This is the normal case for a widget.
  output
      Send value, but do not receive value from user.
      This disables request parameter processing for the widget
      and all of its child widgets, like what we currently use
      the "output" widget for.  This would add the feature to
      all widgets, so for example you could have a read-only
      table driven by an "output" repeater.
  input
      Send no value, but receive value from user.
      This is for passwords or other sensitive values where we
      do not want to echo the value back into the users's form.
  neither
      Do not send value, and do not receive value from user.
      This is for internal values that we do not want to send
      to the user, not even hidden, but where we still want to
      make use of the other features of widgets, such as event
      handling, validation, binding, etc.

We may also need another separate attribute to handle hiding:

  hidden
      Suppress display of value.
      Hiding is actually orthogonal to the settings above,
      because depending on the use-case we may want to pair
      it with any of "both", "output", or "input" widgets.
      For example, a hidden tab-state would be probably be a
      "both" field, a fixed-size repeater may send the size
      as an "output" field, and a widget recording what
      triggered a submit may be an "input" field.

We need to be able to specify the hidden state and the
selection of {both|output|input|neither} both statically in
the widget definitions and dynamically via flowscript, Java,
binding, and event handling, but not via the view, of course.

--Tim Larson

Mime
View raw message