[Seaside] newbie design question
jamie.ashford at gmail.com
Sun Jul 3 15:49:43 CEST 2005
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
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!
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:
> 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.
> Seaside mailing list
> Seaside at lists.squeakfoundation.org
More information about the Seaside