[Seaside-dev] filters initialization with request context?

Julian Fitzell jfitzell at gmail.com
Mon Mar 9 11:33:22 UTC 2009


On Sun, Mar 8, 2009 at 7:09 PM, Sebastian Sastre <ssastre at seaswork.com> wrote:
>> We had some discussion when to make it available, because it is also
>> passed through the lookup chain.
>>
> and what arguments will say not to it? I mean why not to have the request
> context available in the whole "window" Seaside needs to respond a request?
> please have in mind that whatever reason it is should plenty pay for the
> confusivness/inconvenience it would add to developers.

Well, the question becomes, if the current request context dynamic
variable is always in scope, why are we passing the request context
into the request handlers at all? It feels weird if there are two
possible ways of getting at the current request context, and it means
it is possible that they could return different results.

Currently we take the approach (as was previously the case with
CurrentSession in 2.8 and CurrentRequestContext since it was
introduced) of defining that variable in the session (at the point
where we begin dispatching from request handling code into
Application/Session code). The argument is that request handling
classes are explicitly dependent on the request context and therefore
should have it passed in whereas Components, Canvas, etc. are not.

The other option would be to define the dynamic variable at the point
that the request context is dispatched. Part of me likes the
simplicity and consistency of this, but as I said above, I don't like
the two simultaneous ways of getting at it within the request handling
code.

Since RequestFilters can be added to a Session at a time other than
during the initial request, though (or to any other request handler
which has no concept of an initial request to begin with) I don't
think it's going to be very good practice to have them depend on a
request for initialization. It is expected that many request filters
will be added to handlers using the Web UI, for example. I think Lukas
is right that for this case, lazy initialization is the way to go.

Julian


More information about the seaside-dev mailing list