[Seaside] Forms and call:

[Avi Bryant]

On Mon, 19 May 2003, Jim Menard wrote:

> What if the path is not that linear? For example, categories contain
> sub-categories and items. The search takes you to either a single item
> if there is only one match) or to a list of items if there are multiple
> matches.

So, sure, the code won't be quite that linear.  I might start by writing a
SearchAndDisplayTask that looked something like this:

go
  self showItem: self chooseItem

chooseItem
  results := self performSearch.
  ^ results size = 1
      ifTrue: [results first]
      ifFalse: [self chooseItemFrom: results]

showItem: anItem
  self call: (DisplayItem new item: anItem)

chooseItemFrom: aCollection
  ^ self call: (ItemList new items: aCollection)

performSearch
  ^ self call: (ItemSearch new)

Later, I might pull everything but #go up into some abstract Task
class, and derive another subclass (say, ShowAllResultsTask) that looked
like:

go
  self performSearch do:
   [:result |
   self showItem: result]

Ok, so this might be a somewhat odd UI (it would display the full detail
view for each item returned by the search in sequence, moving on to the
next result as you dismiss the current one). But the point is that by
keeping the components themselves as simple and functional (in the sense
of being mostly defined by their inputs and outputs) as possible, you have
much more flexibility in playing with the flow of your application later.

> The item view page lets you go to the category. The category
> lets you go to the parent category, any of the items in the category,
> or any sub-category.

This is navigation, which makes perfect sense to put on the component
itself - in this case I definitely would have a direct #call: from the
item view page into the category pages.  However, even here, I might
separate the notion of picking an item from that of displaying the item.
For example, let's say you were on an ItemEdit page instead of the
ItemView page.  You might want to have a link to the same category
browser, but in this case when you chose a new item from the category, you
would want to be editing it, not viewing it.  One way to achieve this
would be to have the CategoryBrowser simply return whatever item is
eventually chosen.  Then from the ItemView or ItemEdit, you might have
code like this:

browseCategory
  currentItem := self call:
     (CategoryBrowser new category: currentItem category)

That is, you end up back at the same component you started from, but the
current item will have changed.

This particular design might not be what you always want (for example, you
might prefer to just have view/edit links in the CategoryBrowser itself),
but I have found that in general the more you can isolate components from
knowing about each other, the better.

I'm very curious to hear what other patterns people are using for this
kind of thing, or comments on this approach.

Avi