rebuild children - when to do it

Greetings,

In my renderContentOn: method I am making a call to my method
rebuildChildren which reconstructs my children on the fly. This is done
as the first thing in renderContentOn:

The code appears to work.

My question: Is it ok to rebuild my children at rendering time?

Thanks,
Frank

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

No, the state of your component should not be changed by rendering.  Setup
your component in #initialize, or lazily in #children.

Ramon Leon
http://onsmalltalk.com

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

It's not the normal pattern. If your children aren't persisting
between requests then their state isn't being persisted (or rolled
back with the back button).

If you feel your code is working fine, then you may not actually need
components for these "children". If your child components do not have
or need state, you might consider subclassing WAPresenter instead of
WAComponent. These can be created at will and used for rendering. Or
of course you can create any other class that implements #renderOn:
and use that.

If you do want/need components, you should, as Ramon says, usually use
lazy initialization or set up your children when the component is
initialized.

Cheers,

Julian

On Thu, Jul 17, 2008 at 5:55 AM, Squeaker <[hidden email]> wrote: _______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

>
> It's not the normal pattern.
>

Which is why I'd still recommend against it.  It's hard enough stopping new
people from making this mistake as is, without mixing the message with
exceptions.  If someone has to ask, then they should be told "do not change
state during the render phase".  This is even a rule in the code critic.

Once they understand why, they won't need to ask when they can violate that
rule because they'll understand the reason for the rule.

Ramon Leon
http://onsmalltalk.com

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

I don't disagree that the rule "do not change state" in the render
phase is a good one.

My point is simply that many people assume they need a component for
everything when in fact they don't. If you have a class doing
rendering that doesn't have state, then it doesn't need to be a
component and doesn't need to be persisted. If it doesn't need to be
persisted then you *aren't* modifying state in the render phase.

That said, however, I'm looking at the code in 2.9 and 2.8 and while I
swear you *used* to be able to easily subclass WAPresenter, it seems
like it may be a little more awkward now. I still think we should be
doing a better job of pointing out that you can implement any class
with a #renderOn: method and thus reuse rendering code but I think
you're right that we need that properly documented with examples and
it may just be confusing now.

So you're right: Probably best to stick to the simple answer for now...

Julian

On Thu, Jul 17, 2008 at 7:47 AM, Ramon Leon <[hidden email]> wrote: _______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

>  That said, however, I'm looking at the code in 2.9 and 2.8 and while I
>  swear you *used* to be able to easily subclass WAPresenter, it seems
>  like it may be a little more awkward now. I still think we should be
>  doing a better job of pointing out that you can implement any class
>  with a #renderOn: method and thus reuse rendering code but I think
>  you're right that we need that properly documented with examples and
>  it may just be confusing now.

I don't remember having subclassed WAPresenter ever, therefore I don't
know if it works out of the box. Earlier versions of Seaside (somthing
as early as 2.4 or so) had WAView, but that was dropped because it
wasn't used anywhere (the last user was WABrowser).

Furthermore with the transition from the old rendering API to the new
one (which is based on brushes that you instantiate), it is less
necessary to have a specific class like WAView. If required you can
always create a subclass of WACompoundBrush that provides all the
functionality to have stateless and configurable XHTML snippets at
your fingertips.

And as noted above, implementing #renderOn: in specific renderable
objects is quite a common pattern.

Cheers,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

"Lukas Renggli" <[hidden email]> wrote
>>  I still think we should be
>>  doing a better job of pointing out that you can implement any class
>>  with a #renderOn: method and thus reuse rendering code

> And as noted above, implementing #renderOn: in specific renderable
> objects is quite a common pattern.

+1. It would be good to highlight these two use cases. In my case, only
after several months of usage did I discover I was subclassing WAComponent
unnecessarily (thanks to a Lukas posting).

Sophie



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