[Seaside-dev] filters initialization with request context?

[Sebastian Sastre]

> It's not a matter of the cost of refactoring; we're just not yet
> decided what the best solution is.
> 
ok, I get it. I'll not hide I'm influenced by this one transaction per request
approach.
GLASS is also is using it I think. Anyway it's extremely convenient (read web
app dev co$t$). 
Because seeing the http request/answer as one transaction simplifies all
enourmusly.
In the implementation of that, the transaction is "globally" reacheable pretty
much the same as a dynamic variable (which a good designed add no need to
manipulate but the pool does and it has to be globally reacheable for the
process).
I'm telling you this because.. filter and ACID transaction aside, to help decide
on the subject, we should give a try to feel how it goes the dynamic variable
approach. I guess we'll win in the simplification in the same fashion ACID
transactions proved to be convenient. But that is really to be ponderated by the
ones involved with that part of the code. I can't tell about that bunch of
exception handling you mention. They are really so inconvenient? Is good to
guess but is better to try so I ask after trying the approach they still prove
they are a reasonable cost for the simplfication or not?

> >> 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.
> 
oops, I don't have a #handleFiltered: method in my image =:0
this is the second signal about possibly not using the "right" seaside 2.9a2
please help, thanks,
sebastian