[Seaside] #render: and #children. What if I don't?

[Julian Fitzell]

When you render a child component you are *implicitly* defining a tree of
components. #children simply allows the framework to walk the component
tree *explicitly*. The reasons for needing to walk the tree explicitly have
changed over time, which is part of the reason for the confusion.

At one point, for example, we used to walk the tree to give each component
a chance to handle callbacks, so if your component wasn't in #children it
would never see its callbacks. That is no longer the case (which is
actually a bit of a shame because decorations can no longer intercept them,
but I digress).

If you look in the image for users of WAVisiblePresenterGuide and
WAAllPresenterGuide, you will see the current cases where we need to
traverse the tree:

   1. Calling #updateStates: for snapshotting/backtracking
   2. Calling #initialRequest: when a new session is started
   3. Executing tasks (they need to execute outside of the render phase to
   make sure the render phase does not have side effects)
   4. Calling #updateRoot:
   5. Calling #updateUrl:
   6. Displaying Halos for each component in development mode
   7. Generating the navigation path in WATree
   8. Detecting which components are visible/active to support delegation
   (#call:/#show:)

If your child component doesn't rely on any of these things (and doesn't
use any child components itself that rely on any of these things) then
technically everything will work fine without adding it to #children. But:

   - The framework may change in the future to traverse the tree for other
   reasons
   - Add-ons may depend on being able to walk the tree for other reasons
   - It's not great encapsulation to assume that, in the future, components
   you are rendering will never need any of the above nor start using
   sub-components that do

#children has always been a bit of a pain and it might be nice if there was
a more declarative way to explicitly define the component tree, but it is
important that it is defined somehow. It is easy to forget and it might
prevent bugs if you received an error when trying to render a subclass of
WAPresenter that is not returned by #children. I think that could be done
with a little thought.

Finally, Mariano said "I must store the component somewhere...which I may
not requiere". Components are stateful by definition, so if you don't feel
the need to persist your component between render phases, I question
whether it's really a component. If you're doing a bit of stateless
rendering you'd be better to subclass WAPainter directly or even WABrush:
both of these are intended to be used and then thrown away and they will
make it clearer in your mind whether you're relying on things that rely on
#children or not.

Hope that's helpful,

Julian

On 16 October 2014 21:16, Johan Brichau <johan at inceptive.be> wrote:

> As far as my knowledge goes about this part of the Seaside framework,
> #children is important in:
> - a WATask [1]
> - when you don’t override renderContentOn: (falling back to the default
> behavior of rendering the children)
> - in combination with #states when you want to support state backtracking
> with the back button
>
> FWIW, I know and have many components that don’t declare their children
> and it works fine. Of course, I’m not using any of the above in those cases.
>
> Johan
>
> [1] http://book.seaside.st/book/components/tasks/sequencing-components
> On 16 Oct 2014, at 18:43, Mariano Martinez Peck <marianopeck at gmail.com>
> wrote:
>
> Hi guys,
>
> From what I understand, if we have a component called X which, as part of
> the #renderConentOn: (or derivative), does:
>
> ComponentX >> renderContentOn: html
> html render: self componentY
>
> Then we need to add componentY to the #chidlren:
>
> ComponentX >> children
> ^ Array with: self componentY
>
> So..not the question is...it seems in some places I forgot to add it to
> #chidlren and the component still render correctly. At the same time, I
> remember once I was fighting to find a bug and it was exactly because I
> forgot to add the component to #children. So... what exactly happens if I
> DON'T add the component as a #children? What does it get broken?
>
> The second question is...is a bit of a pain the #children. Why? Because I
> must store the component somewhere...which I may not requiere that. For
> example, if I have this code:
>
> html render: (MyWebMessageComponent new errorMessage: 'Problem with xxxx';
> yourself)
>
> then I must define an instVar for that component, assign to it before
> render, and then render...
>
> so the second question is...for this type of component that I render only
> "once" (the component is instantiated as part of the rendering phase and
> dead after), do I also have to add it to #children?
>
> Thanks in advance for any clarification.
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>  _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
>
>
> _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20141019/438e88d3/attachment.htm