[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
children
^ 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
children
^ 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
children
^ self currentItems collect: [:ea | self childForItem: anObject]
currentItems
self subclassResponsibility
Anyone have any others?
Avi
More information about the Seaside
mailing list