[Seaside] #call: #show: #home

Julian Fitzell julian at beta4.com
Tue Oct 11 13:37:02 UTC 2005

Well, mostly it isn't done by default because there are patterns you 
might use where you don't need it.  Using #parent breaks encapsulation 
by requiring that the child be aware of where it is placed, which is 
something I generally avoid to make my components more reusable.

Look at what the component needs the parent for...

Perhaps it needs something to #call: on to pop up alerts... so add an 
#alertTarget: method to properly configure it.  Perhaps it's finding out 
what component is the "content frame" so the main part of an application 
can be replaced without losing the menu.  You could have the child 
determine where this is, but seems wrong.  I usually have a method on my 
session called something like #fromContentPaneCall:  In *general*, it's 
going to be better to have the child configured with the correct targets 
rather than allowing it to determine them.

Now maybe sometimes using #parent is the right way to go (and it's 
certainly not hard to add "child parent: self" if you think it is) but I 
can't remember the last time I've needed it.


Dmitry Dorofeev wrote:
> I am also curious.
> Sometimes i do call: from inside a parent (which is manually set by me).
> I do it mainly for better visual HTML representation of forms or tables.
> Also parent inform: or even root inform: sometimes usefull to say something
> to the user and make him really see it. Especially from inside nested 
> tables,
> where each cell is rendered by separete WAComponent.....
> -Dmitry.
> William E Harford wrote:
>> Thanks
>> I misunderstood the methods' function.
>> Is there a reason that WAComponent does not keep a reference to it's
>> parent?
>> It appears WAComponent are singly linked. Any comments on why this was
>> done? Would there be any major disadvantages in keeping a reference to
>> the parent component in WAComponent? It would be nice if one could
>> traverse upward along the chain (Ofcourse a simple subclass would do
>> this but I am more interested in knowing why it was done the way it was
>> done). 
>> Thanks
>> Will
>> On Tue, 2005-10-11 at 07:21 +0200, Lukas Renggli wrote:
>>>> I assume that #home should return you to the first component in a chain
>>>> of called components. So component 1, calls component 2, calls 
>>>> component
>>>> 3, and executing `self home` from component 3 should return you to
>>>> component 1. Is that correct ?
>>> No, #home removes all the delegation-decorations. This means if you
>>> want to go back to component 1 you have to call home on component 1.
>>> On component 3 it has no effect, after all it wouldn't know how far it
>>> should go back in the chain of called-components, so call #home on the
>>> component you want to show again.
>>>> #show appears to be behaving exactly like #call. I assumed that show
>>>> would replace the current component with the shown component but it
>>>> appears to   delegate. Turning on halos show this.
>>> In most cases #show: works similar to #call:, but there is an
>>> important difference: #call captures a continuation before actually
>>> #show-ing the called component. This makes it possible to have a flow
>>> of pages where you call each component and get the result.
>>>   a := self call: aFirstComp.
>>>   b := self call: aSecondComp.
>>>   c := self call: aThirdComp.
>>>   ...
>>> #show does not return a result (from #answer). However you can do
>>> basically the same using continuation passing style with
>>> #show:onAnswer:, but this is less natural and starts to become
>>> complicated if you have flows with loops and conditions.
>>>   self show: aFirstComp onAnswer: [ :a |
>>>      self show: aSecondComp onAnswer: [ :b |
>>>          self show: aThirdComp onAnswer: [ :c |
>>>              ... ] ] ]
>>> I suggest that you always use #call:, it works as expected in all cases.
>>>> Instead of calling and  delegating to another component (presumably to
>>>> wait for an answer) I would like to replace the current component with
>>>> the called one. I could do this by putting my main navigation element
>>>> outside of the called component but in this case it is not the most
>>>> fitting approach.
>>> Store a reference to the parent component in you child and do a call
>>> on the parent, as you can see in WAParentTest.
>>> HTH,
>>> Lukas
>>> -- 
>>> Lukas Renggli
>>> http://www.lukas-renggli.ch
>>> _______________________________________________
>>> Seaside mailing list
>>> Seaside at lists.squeakfoundation.org
>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>> _______________________________________________
>> Seaside mailing list
>> Seaside at lists.squeakfoundation.org
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
> _______________________________________________
> Seaside mailing list
> Seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

   Julian Fitzell  --  Beta4 Productions
julian at beta4.com  --  http://www.beta4.com
Seaside: http://seaside.st/

More information about the Seaside mailing list