Fw: [Seaside] Form support

[Avi Bryant]

Adrian - yes, this is exactly the kind of thing I was thinking of.  Let's
dig in...

On Thu, 5 Dec 2002, Adrian Lienhard wrote:

> Here some first thoughts... Please comment!
>
> What I use for the form stuff is: Kind of field (text, textarea,
> radiobutton, checkbox, select list) or more complex like date, label and
> description, validation rules, types (may be done by rules).
> "Kind of field" can be devided into text and "select" whereas "select" has
> always cardinality one (for radio and for select list with single selection)
> or many (for checkbox and for select list with multiple selection).

Seems like this stuff can be derived from the more general (relationship,
etc) info below, right?

> So it would be interesting to know the relationships between model objects.
> It could maybe look like this: Each instvar of an domain model has an
> describing attribute which distinguishes between "simple", "relationship"
> and  "collection" (there may be a better naming?).
> -simple: These would be objects like Strings, Numbers, Dates etc. which are
> not direct part of the model.
> -collection: object holds a collection of other simple or non-simple
> objects. But object is responsible for them.
> -relationship: single or multiple (in the latter, the instvar would then
> probably be a collection), to which domainobject (or may there also be 1:1?)

Hmm, I like the distinction between collections you "own" and those that
are relationships.  But I think we should factor out the single/multiple
distinction here.  What I did for the GOODS metamodel was to have a
container + type combination - so, you could combine any container
(SingleContainer or CollectionContainer) with any type (String, Number,
Date, some domain object).  So perhaps we have

Attribute #('name' 'owned' 'attributeType' ...)
  SingleAttribute #()
  CollectionAttribute #()

AttributeType
  RelationshipAttributeType #('domainClass')
  TextAttributeType #(size)
  NumericAttributeType #(...)
  ...

> With this information it would be possible to choose the right "kind of
> field", to populate select lists, to decide if a select list is single or
> multiple select etc.

Yes.  Slightly more difficult is knowing what to populate the select lists
with - in some cases you can ask the entity that owns the attribute for
the possible values, in others the possible values will only be known
externally.  Doing this well will be tricky.

> More information could be: Rules/Constraints, Type, Sorting/Filtering.

Constraints are interesting, because some rules can go on the individual
attributes, but others will have to go on the Model as a whole ("there
must be a value in *either* attribute A or B").  Other info - yes,
sorting, also grouping (can you group by this attribute, and if so, what
equality test do you use?), and summing (how do you total a column of
these?).  Then there's read/write permissions, which should probably be
more than just a boolean flag, but I don't know what.  If we want to get
fancy, maybe some kind of notion of attribute group (first and last name
go together) and ordering (name should go at the top).  Ordering is
closely related to detail level (should this attribute be shown in a one
line listing of the object?  How about in a three line summary?).
Anything else?

> The thing above could also be used for database mapping(?)

Database mappings have to be a little more specialized (in terms of also
having the column names and all that), and O/R frameworks tend to come
with their own metamodel.  However, I can definitely see deriving a rough
Seaside metamodel from, say, a GLORP or Tantalus metamodel.

> What information would other components use?

Well, we probably have enough to start with... ;)  Just a matter of
starting to implement it.  One thing I think is important is to keep the
AttributeModel explicit and separate from the actual domain classes - when
you pass an object into a form, for example, you also pass in the model to
use with it.  That way there are no assumptions made about how the model
is derived (there might be a class side method that returns it, or it
might be built from DB info, or you might hand build one for that particular
form...).

Avi