[Seaside-dev] filters initialization with request context?

[Sebastian Sastre]

> Normally you should be able to access the current request context when
> the filter is initialized.
> 
that sounds good but I'm not able to reach it. I mean a 'self requestContext'
while #initializeFilters is signaling.
Could be me using a wrong version of seaside 2.9a2? 
I've loaded 2.9a2 from the script made by the site (all but tests)

> It shouldn't be necessary to subclass WASession in Seaside 
> 2.9 anymore.
> 
I was guessing that but well, I'm migrating one feature at the time :)

a weird thing I'm seeing right now is that sometimes I get more than one
transaction executed per request. I'm still investigating yet but seems to me
like some ensure: could be unwinding more than once. 

Please correct me if I'm wrong but AFAIK Seaside uses 3 requests at the begining
and then 2 (a redirect and the request/response). So once session is started, it
should be commiting "twice per click" (unless redirect can be made outside a
transaction which is an optimization I didn't investigate yet).

What I see here is that after getting a proper result, 2 o 4 additional commits
are made for the same (already responded) request. That, at some point, ends up
making things get lockes and sh*t like that :P

Is anybody working with a transaction filter and see things like that? 

thanks,
sebastian
PD: I'm using OmniSupport + an upgrade patch I've made.

> Lukas
> 
> -- 
> 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