<div dir="ltr"><div>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.<br><br>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).<br><br></div><div>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:<br><ol><li>Calling #updateStates: for snapshotting/backtracking</li><li>Calling #initialRequest: when a new session is started</li><li>Executing tasks (they need to execute outside of the render phase to make sure the render phase does not have side effects)</li><li>Calling #updateRoot:<br></li><li>Calling #updateUrl:</li><li>Displaying Halos for each component in development mode</li><li>Generating the navigation path in WATree<br></li><li>Detecting which components are visible/active to support delegation (#call:/#show:)<br></li></ol><p>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:</p><ul><li>The framework may change in the future to traverse the tree for other reasons</li><li>Add-ons may depend on being able to walk the tree for other reasons</li><li>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</li></ul><p>#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.<br></p><p>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.<br></p><p>Hope that's helpful,</p><p>Julian<br></p></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 16 October 2014 21:16, Johan Brichau <span dir="ltr"><<a href="mailto:johan@inceptive.be" target="_blank">johan@inceptive.be</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">As far as my knowledge goes about this part of the Seaside framework, #children is important in:<div>- a WATask [1]</div><div>- when you don’t override renderContentOn: (falling back to the default behavior of rendering the children)</div><div>- in combination with #states when you want to support state backtracking with the back button</div><div><br></div><div>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.</div><div><br></div><div>Johan</div><div><br><div>[1] <a href="http://book.seaside.st/book/components/tasks/sequencing-components" target="_blank">http://book.seaside.st/book/components/tasks/sequencing-components</a><br><div><div><div class="h5"><div>On 16 Oct 2014, at 18:43, Mariano Martinez Peck <<a href="mailto:marianopeck@gmail.com" target="_blank">marianopeck@gmail.com</a>> wrote:</div><br></div></div><blockquote type="cite"><div><div class="h5"><div dir="ltr">Hi guys,<div><br></div><div>From what I understand, if we have a component called X which, as part of the #renderConentOn: (or derivative), does:</div><div><br></div><div>ComponentX >> renderContentOn: html</div><div>html render: self componentY</div><div><br></div><div>Then we need to add componentY to the #chidlren:</div><div><br></div><div>ComponentX >> children<br></div><div>^ Array with: self componentY</div><div><br></div><div>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?</div><div><br></div><div>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:</div><div><br></div><div>html render: (MyWebMessageComponent new errorMessage: 'Problem with xxxx'; yourself)<br></div><div><br></div><div>then I must define an instVar for that component, assign to it before render, and then render...</div><div><br></div><div>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?</div><div><br></div><div>Thanks in advance for any clarification. </div><div><br></div><div><div><br></div>-- <br>Mariano<br><a href="http://marianopeck.wordpress.com/" target="_blank">http://marianopeck.wordpress.com</a><br>
</div></div></div></div><span class="">
_______________________________________________<br>seaside mailing list<br><a href="mailto:seaside@lists.squeakfoundation.org" target="_blank">seaside@lists.squeakfoundation.org</a><br><a href="http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside" target="_blank">http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside</a><br></span></blockquote></div><br></div></div></div><br>_______________________________________________<br>
seaside mailing list<br>
<a href="mailto:seaside@lists.squeakfoundation.org">seaside@lists.squeakfoundation.org</a><br>
<a href="http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside" target="_blank">http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside</a><br>
<br></blockquote></div><br></div>