Name: Seaside-Core-lr.189
Author: lr
Time: 29 August 2008, 6:47:42 pm
UUID: a6af2867-e3c7-41eb-a6e8-2fbbafecedc2
Ancestors: Seaside-Core-lr.188

- yet another try at chaning how tasks works

Please provide feedback on Seaside-Core-lr.189. It appears to me that this solves the problem and does not 
break existing code. This also fixes  Issue 16 .

Seaside-Core-lr.189

Name: Seaside-Component-lr.11
Author: lr
Time: 30 September 2008, 6:54:50 pm
UUID: 91dbace0-ee93-4849-8f92-7d7868a58dae
Ancestors: Seaside-Component-jf.10

- restored the old and crappy code of WATask that does a redirect, but that's the only thing that seems to 
work
- this re-opens  Issue 16  and  Issue 121 
- this closes  Issue 191 

See also Issue 136 which should maybe be done before carrying on with this.

(No comment was entered for this change.)

I traced this a bit further tonight.

So Lukas was trying to change WATask so that it runs #go from within
#nextPresentersDo:. The problem with this is that the first time #nextPresentersDo:
is called for the task (at least in this case) is during #updateUrl: in a
WARedirectContinuation.

This means that the continuation is captured with that stack. His code also catches
and ignores WARenderNotifications, which means that when we come back into the
callback, do something else and then trigger a notification, the code carries on as
if it were in the middle of #updateUrl: from the earlier render continuation.

I tried monkeying around with WATask>>nextPresentersDo: and
WARedirectContinuation>>run to see if I could come up with a working scenario but
it's pretty ugly and I can't quite get it to work so far. With the methods
implemented as follows, the functional test sort of works (but the session and
continuation keys are in the form, not the URL, and we don't get a redirect between
action phases).

nextPresentersDo: aBlock
	self activeComponent == self ifTrue:
		[ self answer: self go ].
	super nextPresentersDo: aBlock

run
	| url |
	[url := self url.
	self respond: [ :response | response redirectTo: url ] ]
		on: WARenderNotification do: [ :n | self newRenderContinuation run]


But even if we figure out how to get this working it feels pretty fragile... #call:
works because we know that any time it could be called (ie. during the last callback
of an action phase), it is safe to totally abort what we are doing and start
something else. This just doesn't hold true in the general case of "any time we call
#nextPresentersDo:", I think.

Thank you for the detailled write-up. Your observations match my own observations.

I suggest to close this bug, trying to "fix it" isn't worth the trouble. Tasks are rarely used anyway and the problem can be easily avoided if really needed (by using a callback).

I will look at  Issue 16  then, that's the one with the lightbox.

Yeah I don't think an extra redirect is the end of the world.

I can't help feeling that this might be solvable with some kind of "about to render",
"about to process" notifications that you *could* abort but I haven't really thought
it through.

It could be left open on low priority if you think we might want to try to come back
to it at some point. Otherwise, yeah, close it.

To be reopened later, if necessary.