[TransWarp] peak.web.forms (was re: State of the Onion)

[Phillip J. Eby]

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 
> the
> > 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
>additional widgets.

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.