Yes, children method solved problem.<br>Thank's<br><br><div class="gmail_quote">2012/10/4 Julian Fitzell <span dir="ltr"><<a href="mailto:jfitzell@gmail.com" target="_blank">jfitzell@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hmm... so if you return your sub-task in #children it will work.<br><br>But we normally only insist that you return components that you are embedding, not calling, so this may be a bug.<br><br>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:<br>
<br>WATaskVisitor>>visitTask: aTask<br> super visitTask: aTask.<br> aTask isExecuting ifFalse: [<br> [ self halt. aTask execute ]<br> on: WARenderNotification<br> do: [ :n | (WAVisiblePresenterGuide client: (WATaskVisitor new)) start: aTask ] ]<br>
<br>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.<br>
<br>What do other devs think?<br><br>Julian<br><br><div class="gmail_quote"><div><div class="h5">On Sat, Sep 29, 2012 at 1:05 PM, Denis Kudriashov <span dir="ltr"><<a href="mailto:dionisiydk@gmail.com" target="_blank">dionisiydk@gmail.com</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">Hello.<br><br>I try build little application with WATasks's. And I find strange behaviour.<br>
When I call some WATask inside another WATask like this:<br>
<br>MyMainTask>>go<br> self call: MySubtask new<br><br>I got error due to method:<br>
<br>WATask>>renderContentOn: html<br> "Tasks define behaviour and should not render themselves directly. Behaviour is defined<br> in the #go method, which can use #call: and other methods to display components.<br>
<br> In general, if this method is called, it means that the application has not been configured<br> properly to use Flow and the task was never executed."<br><br> WATaskNotDelegated signal: 'This task has no delegation.' <br>
<br>Which means that #go method not executed for callable MySubtask (I put halt on it).<br>Is this known restriction or it is just bug?<br><br>Best regards,<br>Denis<br><br>
<br></div></div>_______________________________________________<br>
seaside mailing list<br>
<a href="mailto:seaside@lists.squeakfoundation.org" target="_blank">seaside@lists.squeakfoundation.org</a><br>
<a href="http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside" target="_blank">http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside</a><br>
<br></blockquote></div><br>
<br>_______________________________________________<br>
seaside mailing list<br>
<a href="mailto:seaside@lists.squeakfoundation.org">seaside@lists.squeakfoundation.org</a><br>
<a href="http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside" target="_blank">http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside</a><br>
<br></blockquote></div><br>