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:

  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
<[hidden email]> <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
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> Second, I created a blog at
> http://methodsandmessages.vox.com/ specifically for my public
> postings about Smalltalk, and Squeak and Seaside in particular.

Looking forward to many excellent posts to come.

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

> * Each component should render its immediate children
> somewhere in its own
>   render method by calling #render: on the canvas:

Assuming you don't call super renderContentOn:, which will render all child
components, so if you happen to see your children rendering twice, you'll
know what's causing it.

> How did I do?  

Sounds like you've totally grokked it to me.

Ramon Leon
http://onsmalltalk.com

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Hi Randal,

        just a couple of details. See below..
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.
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.
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


_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

2007/12/29, Randal L. Schwartz <[hidden email]>:
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.

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.

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
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside