[Seaside] Wish List (was Re: [Seaside] Browse Toolbar Link)

[Avi Bryant]

On Tue, 26 Nov 2002, Adrian Lienhard wrote:

> What I think will be import for many apps is a good support of forms.

Agreed.  The 2.04 release did some work to make typical form use easier -
for example, instead of writing

  html textInputWithValue: customer name callback: [:n | customer name: n]

you can now write

  html textInputOn: #name of: customer.

I got perhaps a little carried away with, eg,

  html labelledRowWithTextInputOn: #firstName of: customer

which is equivalent to

  html tableRow: [
    html
     cssClass: 'label'; tableData: [html text: 'First Name'];
     tableData: [
       html
         cssId: 'firstName';
         textInputWithValue: customer firstName callback: [:n | customer firstName: n]
     ]
  ]

But then, I really do use rows like that over and over again.

> Some thoughts: There are "rules" which can be defined for each input and
> which are used to validate the form and maybe "convert" the input to the
> right kind of objects.
> This rules may be for example: "required", "minimum/maximum length", types
> like string/number/date. In addition it should be possible to assign an
> Error-Text which will be shown if the validation fails. Maybe there should
> also be the possibility to create global rules (e.g. for: "input1 has to be
> bigger than input2"). These rules may also be hierarchical (when one rule
> fails then another will not be validated).

Yes, a good validation framework would be very nice.  A thought as to how
it could maybe be implemented: we introduce a ValidatingProxy class that
holds on to the model object and uses DNU to trap all accessor/mutator
calls.  As far as the form inputs are concerned, they are dealing with the
real object (they just call the accessors as usual).  However, the proxy
caches the state and doesn't push it back to the real object unless it
validates.  The proxy can also be asked for the current status of any
individual field.  So, when you need a validated form, you create this
proxy, set it up with whatever rules, and hook the form inputs up to it...
you might also have some hidden error messages that are displayed
conditionally based on what the proxy says about validation status.  When
the form is submitted, you ask the proxy whether or not everything
validated (that is, whether the model in fact has been updated yet) before
moving on.

The model should also be able to signal a ValidationError that the proxy
would catch, so that when if the validator is satisfied with the data and
pushes it back to the model, the model has a chance to complain as well.