[TransWarp] peak.web.forms (was re: State of the Onion)
Phillip J. Eby
pje at telecommunity.com
Sun Aug 10 10:03:19 EDT 2003
At 01:28 PM 8/10/03 +0200, Roché Compaan wrote:
> > In general, I prefer to introduce more objects, and have each object
> > responsible for a distinct role. Such objects are usually much more
> > flexible, reusable, and maintainable.
>But this is not a clear cut science - a lot of designs suffer from
>layers of unnecessary indirection and abstraction which makes something
>that is ultimately flexible impossible to maintain.
Indirection isn't the same thing as having clear-cut responsibilities. If
an object has clear responsibilities, then code is easier to write and
maintain, since you don't have to think about the other
responsibilities. The more complex the functionality required, the more
important it becomes to factor it out into separate
responsibilities. Sometimes, it's even useful to further factor the
responsibilities of an object into separate interfaces, to distinguish
between roles that the same object plays.
> > Really, I don't want this to be the normal circumstance. Writing the last
> > email made it clear to me that forms want to drive the application, not
> > other way around.
>It is not that clear to me. I really think it is common to manipulate
>widgets on a form at runtime.
That may be, but it's the form object that should be responsible for the
manipulation. Even in Visual Basic, that's pretty idiomatic.
>Just think of a form where most of the
>widgets are the same for all users but some users are presented with
That kind of behavior could also be controlled by binding the "visible"
and/or "enabled" properties of the widgets to permissions, or by simply
defining widgets as having permissions. But either way, it's still the
responsibility of the form.
>I wouldn't want to create a form for each user just
>to cope with this. And what if the whole form is constructed from a
>datasource at runtime. Let's say I allow users to add custom fields to a
>form or let them build new forms for editing objects all together.
>Surely a separate framework for this shouldn't be necessary.
Those are all things one would do by extending the form classes.
>I don't need it *now*, but I see building prototypes as part of the
>brainstorming process and I think it will help focus our discussion more
>and clarify some of the ideas we throw around.
Don't let me stop you; but prototyping is usually only useful for me when
I'm trying to figure out *how* to do something, not *what* the something is
that I want to do. And I'm still focusing a lot of the "what" right now --
and that includes defining what the full set of use cases are! I think you
have a much more narrowly defined scope of what you want forms to be and
do, and you are also more clear on what you want. I am not nearly so
clear, but I am getting clearer. In a separate post, I'll be laying out
what I believe are some of the use cases, and explaining my thoughts on how
the peak.web.forms should work to handle those use cases.
The short summary of how they should work is that you won't have methods on
your objects to manipulate forms, but instead will have methods on the
forms to manipulate objects. In effect, you'll have the option of defining
a method for each "submit" button on the form, and if you don't override
any of the base form behavior, you'll get a simple (but "smart")
view/add/edit form, that will also work inside of a portal page with other
forms, and will still "know" whether it's the active form or not. Ideally,
the 80% of forms that are view/add/edit forms should be doable by just
defining parameters, and ideally most of those parameters should be able to
come from the underlying object's type definition.
There are a lot of low-level details I'm not 100% clear on yet, especially
as regards "subforms", "repeats", and "groups", but I expect those will get
clearer when I write down all the use cases that I have in mind. Right
now, I have so many zillions of form types bouncing around in my head, that
they all blur together in a sea of controls. Once I write them down, I'll
be able to test designs against them individually. In effect, I have not
yet seen or prioritized all the "user stories", so I don't yet know what
"the simplest thing that could possibly work" is.
More information about the PEAK