[Seaside] Form support

[Adrian Lienhard]

Hi Avi

> 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).

Yes, this is true

> 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 haven't thought too much about layouting yet. It woun't be a big problem
to change the form for use by composition. (Though, I don't exactly see the
point: if you use it by subclassing, you could also create some more special
subclass of the form and then inherit from this one(?) But I see that
composition may be more flexible than subclassing).
For custom layout I intended to simply use the field rendering methods such
as (renderNameOn: or renderInputOn:). This would also be more or less simple
to use for a grafics designer.

>
> - 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?

No, I think this sounds good/interesting. Of course we have to take care not
to do a too complex system just for using a form... What I like as it is
now, is that you can create a fully functional form in just a fiew lines of
code.

> - 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?

Yes, this is stolen ;-). What I didn't like was that it does proxying AND a
validating. So I've thrown all the validation stuff out of the class. But it
doesn't refer to fields or some other special classes...Does it?

Shall we continue on on what I did?
If yes, how/who? I'd like to continue (though not too fast, because I have
not much time left).

Adrian

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