[Seaside-dev] about issue 103

[Lukas Renggli]

> No, no, nothing obviously wrong with the approach, I think. I
>  generally like the request context approach. I was just curious what
>  the grand vision behind it was and I guess I was trying to see how
>  this was better than walking up the #parent chain (or if you were
>  intending to get rid of #parent).

That's true, since 2.8 there is the possibility to walk up the parent
chain. Now I don't see anymore why we wanted to remember all the
request handler?

>  I'd also love to know the rendering context stack somehow... I'm still
>  pondering this refactoring to allow simple stateless component-like
>  objects and it would be nice if they could create callbacks that ran
>  within the scope of their containing component. At the moment, the
>  best I can do is set the callback owner to nil, which works but
>  bypasses any decorations that might be enclosing them (and yes I know,
>  that's another pending discussion :) ).

I changed this in 2.9 that the owner can be left nil, because there
was the requirement to render callbacks in #updateRoot: and also for
AJAX callbacks this sort of avoids many troubles.

Unfortunately my time is quite limited at the moment, I will be able
to chime in at full speed during ESUG and the Seaside sprint ;-)

Lukas

-- 
Lukas Renggli
http://www.lukas-renggli.ch