[Seaside] what I think I've learned about children

[Sebastian Sastre]

Hi Randal,

	just a couple of details. See below..

> -----Mensaje original-----
> De: seaside-bounces at lists.squeakfoundation.org 
> [mailto:seaside-bounces at lists.squeakfoundation.org] En nombre 
> de Randal L. Schwartz
> Enviado el: Sábado, 29 de Diciembre de 2007 15:10
> Para: Seaside - general discussion
> Asunto: [Seaside] what I think I've learned about children
> 
> 
> In the past few days, I've done two things.
> 
> First, I spent about a day going through the prior 11000(!) 
> messages in this mailing list.  Sure, I killed entire threads 
> once I saw what the discussion was about, and I *think* I got 
> pretty good at ignoring the things that were no longer 
> accurate because the methodology has changed.  But it was 
> rather enlightening, and I'm glad I did it.
> 
> Second, I created a blog at 
> http://methodsandmessages.vox.com/ specifically for my public 
> postings about Smalltalk, and Squeak and Seaside in particular.
> 
> Since I just posted here about children, I wanted to post 
> what I think I know about children now, to see if I'm 
> confused about anything, and maybe to make up some FAQ 
> material, both for my blog, and for the seaside.st FAQ.
> 
> So, please correct me!
> 
> * The rendering process is a hierarchy of WAComponent-derived objects,
>   one of which has been designated as the "root" in the configuration.
> 
> * Each component must answer its immediate children in the tree by
>   overriding #children:
> 
Yes, and it can answer more children (like dinamically discarded children)
than the ones that it will actually is rendering. Sounds a feature unlikely
to be needed but I used it once and was important exactly like that.

>   children
>     ^ Array with: topnav with: leftnav with: body.
> 
> * Each component should render its immediate children 
> somewhere in its own
>   render method by calling #render: on the canvas:
> 
>   renderContentOn: html
>      ...
>      html render: topnav.
>      ...
>      html render: leftnav.
>      ...
>      html render: body.
>      ...
> 
I think is the more often scenario, but nothing stops you making a component
rendered twice. A parent can render a deeper sub children even when another
children renders that (repeated) one.

> * A component can temporarily replace itself with a 
> *different* component
>   with #call:.  This should *not* be done as part of the 
> render, because
>   that would be some sort of weird brundlefly experiment.  
> Instead, it will
>   always be as part of a callback:
> 
>   renderContentOn: html
>     ...
>     html anchor callback: [self call: self newbody]; with: 'go here'.
>     ...
> 
>   newbody
>     ^[a different component component]
> 
>   When the anchor is selected, a new render (from the top) 
> will be performed,
>   with the component that called #call: temporarily replaced 
> with the result
>   of #newbody.  It should have its own #renderContentOn:, 
> #children, and so
>   on.  When the component returned by #newbody wants to pop 
> the stack, it
>   calls #answer or #answer: (from a callback!) and the 
> original component will
>   appear again.
> 
> * Use #call: only when you will be coming back.  You can also 
> just change
>   the components instead, if it's unidirectional rather than 
> call and return:
> 
>   initialize
>     super initialize.
>     body := self body1. "set up the initial component"
> 
>   children
>     ^ Array with: body. "don't forget this!"
> 
>   renderContentOn: html
>     ...
>     html anchor callback: [body := self body1]; with: 'first body'.
>     html anchor callback: [body := self body2]; with: 'second body'.
>     ...
>     html render: body. "render the current body"
>     ...
> 
>   Now, picking one of the two links will select which "body" 
> gets rendered.
>   No #call: is needed, because we don't need to stack the 
> states to return
>   to it.
> 
Maybe is "just in case" or "code clean" policy but I still prefer use to use
call: for those cases.


> How did I do?  Would the seaside.st people like me to edit 
> this directly into the FAQ there?  Thanks.
> 

I'm glad to hear someone making this clarifications. Great summary Randal.
All the best with your blog,

Cheers,

Sebastian


> --
> Randal L. Schwartz - Stonehenge Consulting Services, Inc. - 
> +1 503 777 0095 <merlyn at stonehenge.com> 
> <URL:http://www.stonehenge.com/merlyn/>
> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
> See PerlTraining.Stonehenge.com for onsite and 
> open-enrollment Perl training!
> _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside