[Seaside] Forms and call:

[Avi Bryant]

On Mon, 19 May 2003, Jim Menard wrote:

> I started looking at WSMFrame. It looks like WSMFrame uses goto: to
> change the contents of the main part of the page. Should I be looking
> at goto: instead of call:? I also notice that the main component is
> wrapped inside another component that seems to do nothing. Why?

First of all, it sounds like you're using Seaside 2.2.  I would recommend
at this point that you use one of the 2.3 snapshots
(http://http://beta4.com/seaside2/downloads/Seaside2-3b.st is the
latest, although I may put another one up in the next coupla days).

WSMFrame only uses #goto: when someone clicks the "home" link,
abandoning whatever path they were on before.  In this case, there's no
expectation of returning to the current context, and so no need for
#call:.  Most of the SM example does (must) use #call:, however.

I'm not sure what you mean by wrapped in another component; WSMFrame is
the root component.  Or maybe you're talking about the fact that the main
component is inside a WAContainer?  This is a 2.2ism that's no longer
necessary, but just ask if you still want it explained...

Anyway, the approach of using a "frame" component is almost certainly what
you want.  WSMFrame is a little more complicated than necessary because it
dynamically changes the navigation options based on the currently showing
main component, but you'll probably want the same basic structure.

What you were saying about the search page calling the results page
calling the individual item page allows me to make a small style point.
There are two ways you could set that up.  The first is the more typical
web app way of chaining the three pages together, where each one knows the
next link - so the search page, when done, would call the results page,
and so on.  This would look something like this:

SearchPage>>searchButton
  results := self performSearch.
  self call: (ResultsPage new results: results).

ResultsPage>>itemLink: someItem
  self call: (DetailView new item: someItem)

DetailView>>okButton
  self goto: (Home new).

Hopefully you can understand what I'm getting at from that skeleton.
The other, and IMO much better way of doing things is to have each page
#answer the relevant data, and have a method somewhere else that strings
them all together.  This would look more like:

SearchPage>>searchButton
  results := self performSearch.
  self answer: results

ResultsPage>>itemLink: someItem
  self answer: someItem

DetailView>>okButton
  self answer

Home>>performSearch
  results := self call: SearchPage new.
  item := self call: (ResultsPage new results: results).
  self call: (DetailView new item: item).

In 2.3, you could also create a WATask subclass that had the code in
#performSearch as its #go method; you could then embed or call this as a
component from anywhere, and the search process would kick off.

I don't know which way you were picturing doing things, but I thought it
was worth mentioning.

Cheers,
Avi