Smalltalk › Frameworks & Tools › Seaside › Seaside General

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

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

6 messages Options

Mariano Martinez Peck

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

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

Esteban A. Maringolo

Re: #render: and #children. What if I don't?

Mariano:

I also use components as "sophisticated tags", it is, just for
rendering as you do.

As far as I remember from older Seaside versions (dating back to the
"squeak enterprise aubergines server" naming), #children is used for
backtracking and proper handling of the "backbutton problem", it is,
to store the components along the transitions.

If you rely a lot on AJAX and backbutton is not an issue, I guess
#children might be totally ignored. But I couldn't tell.

tl;dr I don't know for sure either :)

Regards,
Esteban A. Maringolo

2014-10-16 13:43 GMT-03:00 Mariano Martinez Peck <[hidden email]>:

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

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

Johan Brichau-2

Re: #render: and #children. What if I don't?

In reply to this post by Mariano Martinez Peck

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

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

Mariano Martinez Peck

Re: #render: and #children. What if I don't?

On Thu, Oct 16, 2014 at 5:16 PM, Johan Brichau <[hidden email]> wrote:

As far as my knowledge goes about this part of the Seaside framework, #children is important in:
- a WATask [1]

Ohhh that sounded a bell. It might have been that in my case.

- when you don’t override renderContentOn: (falling back to the default behavior of rendering the children)

OK, I don't do this.

- in combination with #states when you want to support state backtracking with the back button

mmmm I thought only #states was needed for the backtracking with continuations. So....do I need both then?

Esteban, I was about to answer you this....

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.

Thank you both.

Johan

[1] http://book.seaside.st/book/components/tasks/sequencing-components
On 16 Oct 2014, at 18:43, Mariano Martinez Peck <[hidden email]> 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
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

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

--
Mariano
http://marianopeck.wordpress.com

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

jtuchel

Re: #render: and #children. What if I don't?

In reply to this post by Mariano Martinez Peck

Hi,

Johan already gave a complete answer.
I seem to remember, however, that there is one minor additional case for #children: if you want to use halos on that child component at development time.
Back in the days when I used to use halos to learn Seaside, I think non-children weren't decorated with halos.

Joachim

Am 16.10.14 um 18:43 schrieb Mariano Martinez Peck:

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

-- 
-----------------------------------------------------------------------
Objektfabrik Joachim Tuchel          [hidden email]
Fliederweg 1                         http://www.objektfabrik.de
D-71640 Ludwigsburg                  http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0         Fax: +49 7141 56 10 86 1

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

Julian Fitzell-2

Re: #render: and #children. What if I don't?

In reply to this post by Johan Brichau-2

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:

Calling #updateStates: for snapshotting/backtracking
Calling #initialRequest: when a new session is started
Executing tasks (they need to execute outside of the render phase to make sure the render phase does not have side effects)
Calling #updateRoot:
Calling #updateUrl:
Displaying Halos for each component in development mode
Generating the navigation path in WATree
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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

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

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