[Seaside-dev] filters initialization with request context?

[Julian Fitzell]

On Mon, Mar 9, 2009 at 1:22 PM, Sebastian Sastre <ssastre at seaswork.com> wrote:
>> 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.

Well, it is much more intuitive from within a Component, sure. But I
think implementing "#handle: aRequestContext" on a RequestFilter is
both more intuitive and more concise than having to call "self
requestContext" whenever you want it, storing it in a temporary
variable, etc. Use the dynamic variable everywhere would also mean a
whole bunch of unnecessary exception handling, walking the contexts
over and over.

The primary purpose of a RequestHandler is to handle a request so it
makes sense to pass the request context into its handle method. If
that weren't the case, Smalltalk wouldn't need colons in method names
at all! :)

> 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

It's not a matter of the cost of refactoring; we're just not yet
decided what the best solution is.

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

Right, but the first request is known when the #handleFiltered: method
is first called. That's my point. You don't need to know a request
when the filter is created. There may not even *be* a request when the
filter is created (from a Workspace for example). Even worse, if a
filter is created and configured on a Dispatcher from the *web* UI,
for example, the current request has nothing to do with the requests
that will eventually arrive in that dispatcher.

I think, as far as a Filter is concerned, the first request is the
first one it gets passed to its #handleFiltered: method. I can't think
of anything else that makes sense in the general case.

Let me know if I'm missing your point, though. :)

Julian