WAComponent children

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

WAComponent children

mmimica
Hello!

If I understood correctly, each WAComponent instance is responsible of
answering with an array of its child WAComponent instances. That is
all I know and some things remain unclear to me.
* Why exactly is this needed? It would help me understand how to use
it properly.

* Do I have to return the same children instances? Is the following legal:
myComponent >> children
    ^{child}.
myComponent >> lazyInit
    child := ChildComponent new.
myComponent >> resetChildren
    child := ChildComponent new.

* Do child components, by consequence, need to be instance variables?
Can I initiate child components on the fly like this:
myComponent >> renderContentOn: html
| child |
    child := ChildComponent new.
    html render: child.


--
Milan Mimica
http://sparklet.sf.net
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: WAComponent children

Julian Fitzell-2
Hi Milan,

Components are supposed to be stateful and so are expected to live
longer than a single request. As such, you don't normally create them
without storing them somewhere or calling them. If you are doing this,
you might consider subclassing WAPainter instead.

The reason for #children is so the framework knows about all the
components it will render before rendering. It needs this in order to
save the components' state and to give them a chance to modify the
action URL for example. When you call a component, Seaside already
knows about it. If you create it, store it in an instance variable,
and then render it, you should return it in #children.

Technically you can create components lazily while rendering but as a
general rule I would avoid it. State snapshotting, updating the url,
and updating the document head all happen before rendering, so any
components created during rendering will not have these opportunities
until the next page view.

Julian

On 4/8/11, Milan Mimica <[hidden email]> wrote:

> Hello!
>
> If I understood correctly, each WAComponent instance is responsible of
> answering with an array of its child WAComponent instances. That is
> all I know and some things remain unclear to me.
> * Why exactly is this needed? It would help me understand how to use
> it properly.
>
> * Do I have to return the same children instances? Is the following legal:
> myComponent >> children
>     ^{child}.
> myComponent >> lazyInit
>     child := ChildComponent new.
> myComponent >> resetChildren
>     child := ChildComponent new.
>
> * Do child components, by consequence, need to be instance variables?
> Can I initiate child components on the fly like this:
> myComponent >> renderContentOn: html
> | child |
>     child := ChildComponent new.
>     html render: child.
>
>
> --
> Milan Mimica
> http://sparklet.sf.net
> _______________________________________________
> 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
Reply | Threaded
Open this post in threaded view
|

Re: WAComponent children

mmimica
Julian Fitzell wrote:
> Hi Milan,
>
> Components are supposed to be stateful and so are expected to live
> longer than a single request. As such, you don't normally create them
> without storing them somewhere or calling them. If you are doing this,
> you might consider subclassing WAPainter instead.

You got that right, the components I'm working with right now are stateless and
are not supposed to remember anything between requests. That's why I didn't feel
I need to keep their instances and had a feeling I was doing something wrong.
Perheps they should indeed inherit from WAPainter.


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