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

Philippe Marschall philippe.marschall at gmail.com
Sun Dec 30 22:39:39 UTC 2007

2007/12/29, Randal L. Schwartz <merlyn at stonehenge.com>:
> 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.

Right, but you can create new and additional render loops. An example
for this would be pop ups.

> * Each component must answer its immediate children in the tree by
>   overriding #children:

Note that this needs to be true in the past as well. So if the value
of #children changes over time you need to use backtracking to make
sure the back button works correctly.

>   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:

Right, it should but does not have to.

>   renderContentOn: html
>      ...
>      html render: topnav.
>      ...
>      html render: leftnav.
>      ...
>      html render: body.
>      ...
> * 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.

Right, note that the argument to #call: might as well be a task.

> * Use #call: only when you will be coming back.

A #call: that doesn't return may be ok or not. That depends on your application.

> 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"
>     ...

Don't forget to use proper backtracking in this case.

>   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.
> How did I do?

You did very well.

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

I'll send you a mail with your account details shortly.


> --
> 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

More information about the seaside mailing list