Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Nested tasks don't get started unless #children present #744

Open
GoogleCodeExporter opened this issue Mar 25, 2015 · 1 comment
Open

Nested tasks don't get started unless #children present #744

GoogleCodeExporter opened this issue Mar 25, 2015 · 1 comment
Labels
auto-migrated Priority-High Type-Defect Version-Seaside3.0

Comments

@GoogleCodeExporter
Copy link 

On Sat, Sep 29, 2012 at 1:05 PM, Denis Kudriashov wrote:

> Hello.
>
> I try build little application with WATasks's. And I find strange
> behaviour.
> When I call some WATask inside another WATask like this:
>
> MyMainTask>>go
>    self call: MySubtask new
>
> I got error due to method:
>
> WATask>>renderContentOn: html
>     "Tasks define behaviour and should not render themselves directly.
> Behaviour is defined
>     in the #go method, which can use #call: and other methods to display
> components.
>
>     In general, if this method is called, it means that the application
> has not been configured
>     properly to use Flow and the task was never executed."
>
>     WATaskNotDelegated signal: 'This task has no delegation.'
>
> Which means that #go method not executed for callable MySubtask (I put
> halt on it).
> Is this known restriction or it is just bug?
>
> Best regards,
> Denis

Original issue reported on code.google.com by jfitz...@gmail.com on 8 Oct 2012 at 6:45
@GoogleCodeExporter
Copy link
Author 

Hmm... so if you return the sub-task in #children it will work.

But we normally only insist that you return components that you are
embedding, not calling, so this may be a bug.

The problem is that by the time the WATaskVisitor has executed the task,
the WAVisiblePresenterGuide has already visited the decoration chain, so we
don't notice and execute the subtask. One possible fix is to run a TaskVisitor 
on the Task again if a RenderNotification is caught (the new code is inside the 
#on:do: block):

WATaskVisitor>>visitTask: aTask
    super visitTask: aTask.
    aTask isExecuting ifFalse: [
        [ aTask execute ]
            on: WARenderNotification
            do: [ :n | (WAVisiblePresenterGuide client: (WATaskVisitor
new)) start: aTask ] ]

Probably it's fine, but I'm not sure if it's the best solution or not. We
could grab the decorations before and after, look for a new decoration then
just visit it. Or we could stop using WAVisiblePresenterGuide and use a
subclass or some other visitor entirely to make sure that we execute tasks
before visiting their decorations.

What do other devs think?

Original comment by jfitz...@gmail.com on 8 Oct 2012 at 6:47

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
auto-migrated Priority-High Type-Defect Version-Seaside3.0
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@GoogleCodeExporter