[Seaside] newbie design question

[Jamie Ashford]

Thanks Avi.

I'm going to use the onAnswer method initially and then consider
refactoring the code and introducing a domain model.

One problem that I did encounter with onAnswer (and this may just be
due to my limited understanding of smalltalk) was that:

comp1 := Comp1 new onAnswer: [:val | self selected: val].

did not work. It changed comp1 to be of type WAAnswerHandler and would
not render.

splitting the code onto two lines did the trick...

comp1 := Comp1 new.
comp1 onAnswer: [:val | self selected: val].

Could just be me misunderstanding things...

Many thanks for the quick response and for Seaside in general!

Jamie.

On 7/3/05, Avi Bryant <avi at beta4.com> wrote:
> 
> On Jul 3, 2005, at 2:26 PM, Jamie Ashford wrote:
> 
> > Nearly....
> >
> > The difficulty is more to do with how these three sub-components
> > should communicate with each other.
> >
> > In my task subclass I had code like this:
> >
> > result := call Comp1 new.
> >
> > result2 := call Comp2 new with: result.
> >
> > result3 := call Comp3 new with: result2.
> >
> > I can render all three components onto a single page, as you suggest,
> > but I am not sure how I should pass information between them...
> 
> A few options:
> 
> The three components could be explicitly aware of each other: so,
> Comp1 would have a reference to Comp2, and Comp2 would have a
> reference to Comp3.  You could set this all up in the #initialize
> method of the component creating the three of them.  Actually, what
> I've described might be backwards: I tend to prefer a "pull" model to
> "push", and so would probably structure things so that Comp3 knew
> about Comp2 and Comp2 knew about Comp1, and each one polled the
> previous component on every render to know what the status was.
> 
> However, that probably results in too much dependency between the
> components.  Another option, similar to what you were trying with
> call/answer with the Task, would be to use the #onAnswer: blocks of
> the components to pass information around.  When you're embedding a
> component rather than calling it, that's what's called when you use
> #answer:.  So, it might look something like this:
> 
> initialize
>      comp1 := Comp1 new onAnswer: [:val | comp2 with: val].
>      comp2 := Comp2 new onAnswer: [:val | comp3 with: val].
>      comp3 := Comp3 new.
> 
> Finally, I might use some kind of a domain model that included the
> list state and data inputs and whatnot for this compound page.  I
> would then have all three components share an instance of this model,
> and use it rather than private inst vars to manage their state.  Each
> of them might only know about a small part of the model, and the
> model class would take care of the interactions.
> 
> HTH,
> Avi
> _______________________________________________
> Seaside mailing list
> Seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/listinfo/seaside
>