Fw: [Seaside] Form support

[Adrian Lienhard]

>Or, we (and whoever else) can try to
> coordinate a little bit further and spend some time trying to unify the
> various models we already have (ReportColumn, Field, Validation), being
> careful to keep them separate from any particular UI, and progress from
> there.  Either way works, I leave it up to you.

Let's talk about metamodel!
Maybe with some input we could create a first rough implementation wich I
then can use with the form support.

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

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

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.

More information could be: Rules/Constraints, Type, Sorting/Filtering. The
thing above could also be used for database mapping(?)

What information would other components use? How could this be generalized?
How implemented?
Avi, is this somehow in the direction you thought?

Cheers,
Adrian

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

From: "Avi Bryant" <avi@beta4.com> Sent: Tuesday, December 03, 2002


>
>
> On Tue, 3 Dec 2002, Adrian Lienhard wrote:
>
> > 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).
>
> What I'd like to do, long term, is define a standard metamodel that will
> be used whenever you need to describe your data to Seaside components -
> for example, the TableReport, the Form stuff you're doing, validation, and
> so on.  What I mean by metamodel is something like WAReportColumn - it has
> a lot of information about a particular attribute (selector, name, sort
> order, how to total) without holding any actual data or doing any
> rendering.  However, I'd like this to be extended to also hold the kind of
> information a Form would need (description, type, size, validation rules),
> and it should continue to be extended as more components require it.
> Then, if your entities know how to provide this metamodel, you wouldn't
> need to set it up for each form/report/etc - you'd just have to specify
> the names of attributes you were interested in.
>
> So, there are two ways we could go - you can explore the Form stuff you've
> done further, not worrying about my long term goals, and once you've
> figured out what the Form side of things requires, that will figure into
> designing the broader model.  Or, we (and whoever else) can try to
> coordinate a little bit further and spend some time trying to unify the
> various models we already have (ReportColumn, Field, Validation), being
> careful to keep them separate from any particular UI, and progress from
> there.  Either way works, I leave it up to you.
>
> Cheers,
> Avi
>
> _______________________________________________
> Seaside mailing list
> Seaside@lists.squeakfoundation.org
> http://lists.squeakfoundation.org/listinfo/seaside