[Seaside-dev] filters initialization with request context?

[Sebastian Sastre]

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.
> 
I'm with you about feeling weird the two approaches. So, you see the dynamic
variable approach is more intuitive and consise and it is not adding major
technical inconveniences but historical reasons (handlers) are retaining you to
do the right thing.
I say to get rid of passing it as argument then. 
The cost of refactoring that handlers to work in the 2.9 today will be
purchasing a real valuable simplification for all from now on. You can also see
it this way: the next guy that asks you about this you'll be answering in one
short sentence instead of 3 pharagraphs ;)
Whoever simplify this, seasiders will send him love :D

> 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.
> 
why not? I don't get you. It is not a good practice or is the way to go :)
I think is the way to go and lazy initialization of the transaction filter is
what I'm trying to do here. As said, I'm with the case of a service which uses
the subdomain of the request to decide which database has to open. I'm using one
database per subscriber account so I need the request at that point to discern
what to do with it. The filters could be configured lazily or not but the
database for the transaction filter *has* to be lazy *in the first* request.
After that it's application responsibility to know what to do (even for invalid
requests/accounts).

I bet you already know this a common pattern for modern services based on rich
web applications like:  http://julian.someservice.com

cheers,
sebastian

> Julian
> _______________________________________________
> seaside-dev mailing list
> seaside-dev at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev