[Seaside] Form support

Avi Bryant seaside@lists.squeakfoundation.org
Mon, 2 Dec 2002 14:41:37 -0800 (PST) 

Nice work.  I'll look at it more later tonight, but a few rough
comments:

- It seems like you're probably intending for this to be used via
subclassing (though I haven't looked at your sample app yet).  I think it
might work better as composition (a generic Form component that other
components would instantiate and configure).  The main reason for this is:
- It would be neat to play with subclasses that did different automatic
layouts.  This would probably mean pulling #renderOn: out of Field (as
each subclass will have different default rendering).  Also,
- For something like a TableForm, you could provide it with a simple spec
that told it what order to lay things out in, eg,

tableForm layoutSpec:
  #((firstName lastName)
    (phone)
    (save cancel))

would produce a table with three rows - first name and last name (with
labels) along the top, then the phone number (with label), then the save
and cancel buttons.  There might be a CSSForm that took the same spec and
rendered it differently.  If you needed a totally custom layout, of
course, you would still write your own subclass.

- I'd like to keep the Field classes one step up in abstraction from
actual form inputs.  So, I don't really want both a TextInputField and a
TextAreaField, but rather a single text field that picks the right HTML
based on, eg, the size parameter.  In fact, I wonder if the best might be
to have three class hierarchies:
   - Fields are purely semantic, don't know anything about rendering (so,
they know data type, name, validation, and maybe some hints as to size
etc)
  - LayoutPolicies render the infrastructure of the form (tables, etc) but
know nothing about the actual inputs
  - InputPolicies do the actual html rendering, and make the choices as to
whether, eg, a particular list is shown as a <select> or as radio buttons.

Maybe that's too complex?

- It seems like you've stolen my ValidationProxy for use in this
framework.  I'd rather keep it generic enough that it could be used just
with the straight HtmlRenderer if desired (as it was, it could have been
used with Morphic, for that matter), so it shouldn't refer to fields
directly.  Does that make things too difficult?

Cheers,
Avi

On Mon, 2 Dec 2002, Adrian Lienhard wrote:

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