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

Randal L. Schwartz merlyn at stonehenge.com
Sat Dec 29 17:10:15 UTC 2007


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:

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

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

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

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


More information about the seaside mailing list