[Seaside-dev] about issue 103

[Julian Fitzell]

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).

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 :) ).

Julian

On Sat, Aug 2, 2008 at 4:01 PM, Lukas Renggli <renggli at gmail.com> wrote:
> To know all the involved dispatcher is cool, because it makes it much
> easier to parse the path, e.g. to know what part of the URL already
> has been handled by Seaside and what part is up to the application.
>
> Maybe this is the wrong approach?
>
> Lukas
>
> On 8/2/08, Philippe Marschall <philippe.marschall at gmail.com> wrote:
>> 2008/8/2 Julian Fitzell <jfitzell at gmail.com>:
>>> No strong opinions (don't like the #do... version of the method name)
>>> but I'm wondering if you could explain what was the goal behind having
>>> the request handlers push themselves onto a stack. I'm not questioning
>>> it (seems like it could be useful), I'm just curious what you are
>>> planning to use the information for, having missed out on that
>>> discussion, obviously.
>>
>> It allows accessing all the contextual information like the
>> application, the session and the dispatcher(s). Instead of making each
>> of them a special case we simply push all of them on the stack and you
>> can access what you need.
>>
>> Cheers
>> Philippe
>> _______________________________________________
>> seaside-dev mailing list
>> seaside-dev at lists.squeakfoundation.org
>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>>
>
>
> --
> Lukas Renggli
> http://www.lukas-renggli.ch
> _______________________________________________
> seaside-dev mailing list
> seaside-dev at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>