WATask does a redirect

[GoogleCodeExporter]

See subject

Original issue reported on code.google.com by renggli on 29 Aug 2008 at 4:50

[GoogleCodeExporter]

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

Original comment by renggli on 29 Aug 2008 at 4:50

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

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.

Original comment by renggli on 29 Aug 2008 at 4:59

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

Seaside-Core-lr.189

Original comment by renggli on 30 Aug 2008 at 10:04

• Changed state: Fixed
• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

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

Original comment by renggli on 30 Sep 2008 at 4:55

• Changed state: Accepted
• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

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

Original comment by [email protected] on 5 Oct 2008 at 12:33

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

Original comment by [email protected] on 5 Oct 2008 at 12:33

• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

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.

Original comment by [email protected] on 7 Oct 2008 at 10:37

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

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.

Original comment by renggli on 8 Oct 2008 at 6:10

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

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.

Original comment by [email protected] on 8 Oct 2008 at 8:13

• Added labels: Type-CleanUp
• Removed labels: Type-Defect

[GoogleCodeExporter]

To be reopened later, if necessary.

Original comment by renggli on 8 Oct 2008 at 8:28

• Changed state: WontFix
• Added labels: ****
• Removed labels: ****