[Seaside] dynamic subcomponents proposal

Jim Benson jb@speed.net
Sat, 15 Jun 2002 20:18:44 -0700


Let me ask questions in a related area.

I've found myself trying to do something layout wise analagous to:


Note that I'm not interested in the web site, just the layout and the way it
Conceptually, on the left there is a a menu. I select a menu item, and the
content pane shows the associated information. There are no frames or
anything involved, the layout is done using tables.

In  the way I want to use it, the content pane could hold things such as
forms and input boxes and such.

 In my current trips to the Seaside, i've been using multiple <if>
constructs in my template, the <if>s determining which of several
subcomponents are placed into the content pane table. Is there already an
elegant way to do this that I am unaware of? It sounds similar to the
problem that you are describing here.

> - rather than configuring subcomponents in an #addHandlers (or
> #addBindingsTo:) method, each subcomponent will have a creation method in
> its parent.  These will follow some sort of naming convention, ie, the
> subcomponent named 'questionPane' would be created by
> #subcomponentQuestionPane.  The responsibility of this method is to
> create, configure, and return a subcomponent.  For example, it might look
> like
> subcomponentQuestionPane
>   ^ QuestionComponent new
>       message: 'Answer the following question:'
>       onDisplay: [:q | q question: self question]
>       onUpdate: [:q | answer := q answer]
> - if the creation method takes 0 arguments, it is called only once in a
> component's lifetime
> - if the creation method takes 1 argument, it is called for every display
> of the subcomponent, and is passed the current instance of that
> subcomponent.  The method can choose to return either the existing
> subcomponent or a new one.  For example,
> subcomponentQuestionPane: current
>   ^ current class = self question componentClass
>       ifTrue: [current]
>       ifFalse:
>        [self question componentClass new
>            ...]

Let me ask this. In the previous context I described, I want to be able to
select a menu item, and then perform a form based edit of a data structure
in the content pane. For sake of example, let's say a customer information
record. So I select, "customer edit" in the menu pane, and a customer edit
pane shows in the content pane. The usual 'cancel' and 'accept' buttons also
appear in the content pane. Typical transaction stuff.

But what I think it needs to do (though I'm not really sure) is do some type
of #callPage: to bring up the content pane, along with the #isolate: stuff
for transaction integrity.

So what I want to do is have a 'dynamic' container, where I just say some
magic like 'call page and throw it in this dynamic container' in the parent.
I'll just note that in the MVC view of the world my bias is put the control
as far away from the model as possible, i.e. I'm more likely to have a child
query the parent for information it needs rather than the parent strictly
controlling the child. I keep having this urge to say, "build me one of
these subcomponents with these initial parameters, and add it into this
magic variable area" (where the magic variable area tends to be a table) and
refresh the web page.

> Comments:
>  - are those rules too implicit?  Is there a better way to do it (split it
> into two methods, one to decide whether to create and one to create)?

I don't think that the #onDisplay: method is intuitively named for
subcomponent initialization, from the parent or subcomponent perspective.

>  - this draws a very strong line between simple template elements (ie,
> checkboxes) and full subcomponents.  I used to think that was a bad idea,
> but it's bothering me less these days.

That seems right, I would assume that a subcomponent is composed of simple
template elements and has other (optional) information associated with it.
The simple elements pretty much map straight to HTML, and the subcomponents
are more concerned with intelligent grouping and data structuring issues.