[Seaside] Form support

[Adrian Lienhard]

Hi Avi and all other Seasiders

I started using your form support implementation. Then I ended up doing a
more whole support for forms using your proxy and rules (for some discussion
see end of mail). I don't know - maybe you have worked more on this since
the release of 2.06. Please have a look on what I did and give me some
feedback. You may want to use it, change it or whatever.

How it works:
A form holds "fields". A field is an entity which bundels the Name,
Description (optional, additional information to the input), Input itself,
Errormessages etc.
One can add validation-rules to fields.

To create a new form, all you have to do is defining fields and adding rules
to them. That's all to have a fully functional form. There is a standard
rendering of the form and fields which will be handy for fast prototyping.
When submitting the form, the validation is done and the proxy commits the
data or the form is shown again with the errormessages to each field.

Creating a field looks for example like this:

nameField _ WATextField on: self model for: #name.
nameField
      fieldname: 'Lastname';
      fielddescription: 'This is some description to this field';
      maxlength: 50;
      addRequiredFieldRule.
self addField: self nameField.

To render the field:
html render: (self fieldNamed: #name).

This leads to much more simple rendering methods (better separation).

What's missing:
- tests (what I would do next)
- More field and rule classes (just text and date and fieldrequired-rule are
done yet)
- maybe rules which depend on others ("only test rule x if y succeeded")
- type conversions and rules (e.g. test if numeric and create appropriate
object)
- ...

The DVS st-files are here (I change some Seaside classes, so maybe don't use
your productive image ;-)):
Form support: http://www.adrian-lienhard.ch/files/squeak/Seaside-Form.st
my app I work on (has a very simple example for usage):
http://www.adrian-lienhard.ch/files/squeak/CTM.st

Adrian

_____________________
Adrian Lienhard
www.adrian-lienhard.ch
www.netstyle.ch

----- Original Message -----
From: "Avi Bryant" <avi@beta4.com>
To: <seaside@lists.squeakfoundation.org>
Sent: Tuesday, November 26, 2002 11:39 PM
Subject: Re: [Seaside] Wish List (was Re: [Seaside] Browse Toolbar Link)


>
> 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
[...]
> > 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.
>
> _______________________________________________
> Seaside mailing list
> Seaside@lists.squeakfoundation.org
> http://lists.squeakfoundation.org/listinfo/seaside