[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.
Cheers
Philippe
> --
> 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