[Seaside-dev] filters initialization with request context?

[Sebastian Sastre]

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

> A link/submit normally creates two requests, as it did in all previous
> versions of Seaside. The first one is to process the callbacks, the
> second one to perform the rendering. This feature is crucial to make
> the back button cleanly work.
> 
ah, I was aware of the two phases but I didn't know is one phase for each
request. That was educative, thanks.

> At the beginning there is just a single render pass, no redirects. If
> you use tasks, there is a redirect whenever a new task starts. This
> has been fixed in the latest code, but I guess this was after 2.9a2.
>
exactly, I receive things in a task to ensure the login.
 
> > transaction which is an optimization I didn't investigate yet).
> 
> True, normally it shouldn't be necessary to commit after a 
> rendering pass.
> 
cool, can you give me a hint in how to I can make aware my transaction filter
about using or not a commit? Is something I can check in the incoming request?
mmm I think I can use a read only transaction for the render phase that could
make this a bit faster.

> 
> Can you print these requests to the transcript or inspect these? To me
> it looks like these requests should not happen. Maybe these are some
> resources that are not found?
> 
I've also was sceptic about what was being requested. ok, doing it... I've used
Live HTTP headers and effectively the requests where hitting the app. That's a
relief, no phantom commits from an internal source.
I'm still ignoring the origin of those requests, let me check something.... dam!
was f* YSLow. Using chrome that is not happening and the only couple of extra
requests where the kalseyTab.css and window.css. I've disabled YSLow in FF now
and is looking normal.

thanks for being supportive,
cheers,
sebastian
PD: I can't use #evaluateAndCommitIn: because transaction gets never commited
with it (I guess thats because the continuation kills the process not unwinding
the ifCurtailed: there). Here is the version I've found working well:  

XXPool>>evaluate: aBlock readOnly: isReadOnly commit: hasToCommit for:
aRequestContext
	"Note: I'm sending aRequestContext only to get some debug info"

	|activeProcess currentTransaction previousTransaction|

	^ self withClientDo:[:omnibase| 
		activeProcess := Processor activeProcess.
		currentTransaction := isReadOnly
						ifTrue: [omnibase
newReadOnlyTransaction]
						ifFalse: [omnibase
newTransaction].

		previousTransaction := OmniBase currentTransactionOrNil.
		OmniBase currentTransaction: currentTransaction.
		hasToCommit
			ifTrue:[
				aBlock ensure:[
					[OmniBase currentTransaction commit]
ifCurtailed:[
						"so things won't remain locked
if sh*t happens"
						currentTransaction abort].
					OmniBase currentTransaction:
previousTransaction]]
			ifFalse:[
				[aBlock evaluateIn: currentTransaction]
ensure:[OmniBase currentTransaction: previousTransaction]]]



> Cheers,
> 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