[Seaside] Sushi Store and WABatchSelection

[Chris Cunnington]

Hi Richard, 


My short short answer:

This won't work. Period. I think that even an expert would not try to do
what your suggesting, but to start from scratch. You're in the weeds,
Richard. Step back from the computer. Find a blank piece of paper and a
pencil, and start fresh. I'm more than happy to be proved wrong, but I think
you've caught yourself in a net.

Chris 


My short explanation:

You can't. Not without adding another layer, another class. The frame area
that the sushi selector component is displayed in (WABatchSelection,
WAStoreItemView) is governed by the instvar main. You want to skip the
Browse button and have the frame governed by the instvar main go directly to
displayItems:. 

How do you get anywhere in Seaside? You either initialize an instvar, or
call: something on top of an instvar. If you go to
WAStoreFillCart>>initialize and change the main instvar initialization to
main := WAStoreFillCart, then you have an infinite loop. How are you going
to call WAStoreFillCart onto itself so that it lands in the frame governed
by the instvar main? It won't work. You'd have to refactor in a big way to
do what you're suggesting.


My long explanation:

I avoid WABatchSelection like the Bermuda Triangle, but I'm willing to try
and talk it out with you. We're not alone in our confusion. The
Hasso-Platter tutorial refers to something called WABatchList, which doesn¹t
even exist. It's in Ch.2 in the paragraph following, "So what does this
mean?" (There's WABatchSelection and WABatchedList. That is all.)

First. Your problem. You want to remove the Browse button, so when people
come to the page they are immediately and automatically presented with a
list of Sushi. 

If that's not the problem, then I don't understand, and you can help me.

Let's back up. Forgive me if I get overly simple about this, but always pull
far back when I'm confused.

This knot of code centers around a dialog called WABatchSelection. We're
pulling in a canned class from the dialog box and we're managing THREE
rendering components with it. That's a lot. And the code is succinct.

The three rendered faces are: 1. The list of sushi to choose from; 2. The
magnified view of a single piece of sushi, which also allows us to add it to
our cart; and, 3. The pane that appears when we have something in our cart.

You want the Browse button to go away, and to have option one appear by
default. 

Those three classes are in order: 1. WABatchSelection; 2. WAStoreItemView;
and, 3. WAStoreCartView.

1. WABatchSelection is requested by displayItems:
2. WAStoreItemView is requested by displayItem:
3. WAStoreCartView is requested by WAStoreFillCart>>renderContentOn:

Whoops. My first mistake. WAStoreCartView has nothing to do with our
problem, as is it doesn't enter the Black Hole that is WABatchSelection.

So, it looks as though the Black Hole only manages:

1. WABatchSelection
2. WAStoreItemView

Check out the last line of displayitems:

[self displayItem: (main list)] repeat.

Pow! That's got a lot going on in it. WABatchSelection is inside that list
temporary variable. DisplayItem: is calling WAStoreItemView. And look at
that repeat! I tell you: Something is afoot at the Circle K!

This problem starts to look to me to be about singular and plural. We start
out with a plurality of pieces of displayed sushi, when we click browse.
Then we go to a singular piece of sushi.

What is presenting that list of sushi?

WABatchSelection>>renderContentOn: has a loop. It says present everything
you've got. Show everything. But I think this tendency of our off-the-shelf,
dialog component is being suppressed.

It's being suppressed in displayitems: here:

aCollection size = 1 ifTrue: [^ self displayItem: aCollection first].

Look at that first. I think the Collection is only ever allowed to be one
item long. That gets sucked into the list temporary variable by way of the
class WABatchSelection. The only reason the page that is displayed after I
press Browse has more than one item is that repeat at the bottom of the
method and after that block. That's where the loop is. WABatchSelection has
a looping mechanism, but it's being suppressed.

OK that gets me to the first page after the Browse button. How do I get from
the plurality page to the singular page?

OK, now I'm cooking with gas.

WABatchSelection creates the anchors we use in the plurality page. Comme ca:

callback: [ self choose: each ]

What does the choose: selector do?

self answer: anItem

Ah-ha!

It sends us back where we started with using a cargo-carrying answer:
selector. The sushi we chose is in anItem. But I've forgotten. Where did we
call: from? 

We started out with one of the call:'s we've encountered on the way. I'd say
the one in displayItems: (isn't that what we just did?). Now the flow of
control switches to displayItem: We are in the singular now. And look, the
anItem we carried back from the Black Hole is the requirement of
displayItem: 

displayItem: anItem

Then this selector renders. We see the content of renderContentOn: has taken
us to the next component, as we'd expect it: a single item of sushi
presented now with two buttons.

That seems to be what's happening. But I haven't solved your problem yet.