Is seaside supports calling subtask inside task?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Is seaside supports calling subtask inside task?

Denis Kudriashov
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


_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Is seaside supports calling subtask inside task?

Julian Fitzell-2
Hmm... so if you return your 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 the following:

WATaskVisitor>>visitTask: aTask
    super visitTask: aTask.
    aTask isExecuting ifFalse: [
        [ self halt. 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?

Julian

On Sat, Sep 29, 2012 at 1:05 PM, Denis Kudriashov <[hidden email]> 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


_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside



_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Is seaside supports calling subtask inside task?

Denis Kudriashov
Yes, children method solved problem.
Thank's

2012/10/4 Julian Fitzell <[hidden email]>
Hmm... so if you return your 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 the following:

WATaskVisitor>>visitTask: aTask
    super visitTask: aTask.
    aTask isExecuting ifFalse: [
        [ self halt. 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?

Julian

On Sat, Sep 29, 2012 at 1:05 PM, Denis Kudriashov <[hidden email]> 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


_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside



_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside



_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Is seaside supports calling subtask inside task?

Philippe Marschall
In reply to this post by Julian Fitzell-2
On Thu, Oct 4, 2012 at 8:00 PM, Julian Fitzell <[hidden email]> wrote:

> Hmm... so if you return your 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 the following:
>
> WATaskVisitor>>visitTask: aTask
>     super visitTask: aTask.
>     aTask isExecuting ifFalse: [
>         [ self halt. aTask execute ]
>             on: WARenderNotification
>             do: [ :n | (WAVisiblePresenterGuide client: (WATaskVisitor new))
> start: aTask ] ]

I assume the #halt is debug code.

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

Can you create an issue so that we don't forget this?

Cheers
Philippe
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Is seaside supports calling subtask inside task?

Julian Fitzell-2
On Sun, Oct 7, 2012 at 9:59 PM, Philippe Marschall <[hidden email]> wrote:
I assume the #halt is debug code.

Erm, yes.

Can you create an issue so that we don't forget this?


_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside