[Seaside] Is seaside supports calling subtask inside task?
jfitzell at gmail.com
Thu Oct 4 18:00:37 UTC 2012
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:
super visitTask: aTask.
aTask isExecuting ifFalse: [
[ self halt. aTask execute ]
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?
On Sat, Sep 29, 2012 at 1:05 PM, Denis Kudriashov <dionisiydk at gmail.com>wrote:
> I try build little application with WATasks's. And I find strange
> When I call some WATask inside another WATask like this:
> 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
> 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,
> seaside mailing list
> seaside at lists.squeakfoundation.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the seaside