[Seaside] #children

Avi Bryant avi.bryant at gmail.com
Mon Mar 28 12:54:47 CEST 2005

On Mon, 28 Mar 2005 18:18:06 +0800, Yar Hwee Boon <hboon at motionobj.com> wrote:

> Would it be a good practice to have a default implementation that
> construct this list from the component's (and parents) instance
> variables?

Yes, perhaps.  Alternatively, there probably aren't that many patterns
of subcomponent usage, and we could write standard components that you
can subclass for each of them.  The ones that come to mind for me are:

- parents with a single static child (for example, I often have a main
"frame" component that provides banners and basic navigation with
whatever the current "main" component is inside).  This could have a
simple #contents, #contents: interface, with

   ^ Array with: self contents

- variations on the above but with two and three children (for typical
two-column and three-column layouts).  These could use #left, #right,
#center or something like that.

- parents with multiple possible children but only one showing at once
(for example, a tab panel).  This could have something like #options,
#selected, and #selected: as the interface.  This would have

  ^ Array with: self selected

- parents which show one child for each of a collection of items (for
example, a complex search result listing that uses a separate
component for each item, probably different component types based on
the class of the item).  I tend to use a dictionary of children with
lazy initialization, so this would look something like:

childForItem: anObject
   ^ children at: anObject ifAbsentPut: [self newChildForItem: anObject]

newChildForItem: anObject
   self subclassResponsibility

  ^ self currentItems collect: [:ea | self childForItem: anObject]

   self subclassResponsibility

Anyone have any others?


More information about the Seaside mailing list