[Seaside-dev] tasks without flow

[Julian Fitzell]

On Tue, Dec 15, 2009 at 2:02 AM, Lukas Renggli <renggli at gmail.com> wrote:
>> But, I ran into an issue: #show: and #show:onAnswer: do not signal a
>> RenderNotification, which means #go returns immediately, which causes
>> the Task to answer immediately.
>
> I think the behavior of #show: and #show:onAnswer: is correct. It is
> documented as non-blocking and useful even in a world with
> continuations, for instance to perform multiple calls in one request.
> I know of quite some code that depends on this behavior (especially in
> the AJAX world, but not only).
>
>> I feel that they should signal the notification, but people may (?) be
>> counting on the method returning, particularly if calling it from Ajax
>> requests. We could add some other selector that doesn't signal the
>> notification?
>
> I think there is rather something wrong with WATask. Maybe it should
> not loop? Alternatively I would just say that people have to throw the
> render notification themselves, when they use #show: to tell the
> system when they want the rendering to happen.

I can "fix" the looping (I originally included some discussion of that
in the email but decided it wasn't really the key issue here).

I totally agree that there should be a method that simply delegates,
and maybe it should even be called #show: (particularly given legacy
usage). However, I think there also should be a method that behaves
like #call: but with an explicit continuation. Writing a Task without
continuations is really wonky right now. For example, you would have
to write:

go
  self show: MyComp1 new onAnswer: [ :a1 |
    self show: MyComp2 new onAnswer: [ :a2 |
      self show: MyComp3 new ] ].
  WARenderNotification signal

That's totally weird to have to write that just because I don't have
continuations - clearly what I want is something that behaves like
#call: but without continuations. Every usage I could find in Seaside
code itself actually uses it in the same way (having been translated
from #call: in the first place) but because they are the last line in
the callback it happens to not matter.

Fixing the looping doesn't help: the task has no way of knowing in
this case whether #go returned because the task was finished or
because you were using show instead of call.

Does that make sense? Can we at least agree the method should exist
(and worry about the name separately)?

I suppose we could have #call:onAnswer: ? Would that be clear?
Unclear? One disadvantage, since #call: is already used, is I don't
know what to call the version that doesn't take a block.
#goto:/#goto:onAnswer: ??

Julian