Can I know if a WATask answered?

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

Mariano Martinez Peck wrote

Hi guys,

There is an scenario that I don't know how to deal. I have a main component
that displays tabs. Each tabs render a component. This component could be
anything, including a task. The tab has correctly defined the #children.
And the way the tab displays its current contents (a component) is via:
 "self activeTabComponent renderOn: html"

Just curious but why aren't you just doing a:

html render: self activeTabComponent

?

The problem is if "activeTabComponent" is a Task. Since I am not doing not
replacing anything (calling), I do not use #call: but #renderOn: as
displayed above. The task can, at any point in time, or when the user
clicks "Finish" do a "self answer: nil". I don't know what happens with
this "self answer:" because I didn't do a #call: to that task.

Anyway... I would like to hook from my main component and I would like to
know if the task has answered or even if the #go method finished so that I
can automatically close the tab and remove this task.  Of course, I can
pass the main component to the task, and then from the task itself tell the
main component that he has finished...but I don't like this very much.

Any idea?

How do you like the idea of using Announcements?

Hi guys,

There is an scenario that I don't know how to deal. I have a main component that displays tabs. Each tabs render a component. This component could be anything, including a task. The tab has correctly defined the #children. And the way the tab displays its current contents (a component) is via:  "self activeTabComponent renderOn: html"

I am using VA Smalltalk, and there are no Continuations there, so I either use show:onAnswer: or the direct rendering of child components like you do.

The problem is if "activeTabComponent" is a Task. Since I am not doing not replacing anything (calling), I do not use #call: but #renderOn: as displayed above. The task can, at any point in time, or when the user clicks "Finish" do a "self answer: nil". I don't know what happens with this "self answer:" because I didn't do a #call: to that task. 

Hmm. There are several things to note here. First, you can always use onAnswer: to execute a Block whenever a component answers. So there is no need call: a component in order to get an answer. The only difference is that this is a Block that gets executed as sson as the component answers:, but it doesn't halt the normal execution of a calling method as in call:/answer:.

So you can always do something like;

self activeTabComponent: (MyTaskOrComponent new onAnswer: [:answer| self handleAnswer: answer]).

Another cool place to use this if you have a JQDialog and need its answer when it's closed.

Anyway... I would like to hook from my main component and I would like to know if the task has answered or even if the #go method finished so that I can automatically close the tab and remove this task.  Of course, I can pass the main component to the task, and then from the task itself tell the main component that he has finished...but I don't like this very much.

Although I fully agree: Sometimes it is the only thing that works. Apart from some publish/subscribe mechanism like Announcements. But Announcements are dangerous if you don't clean up subscriptions once your component is gone. I once hunted for strange duplicate INSERTs to the Database, just to find out that some old Components still handled announcements although they had long disappeared from the tree of visible components... I lost a couple of hours if not days with this ;-)


Does this help? If not, maybe you can give a few more details on your situation.

Happy day at the Seaside,

Joachim

Any idea?

Thanks in advance 

--
Mariano
http://marianopeck.wordpress.com

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

-- 
-----------------------------------------------------------------------
Objektfabrik Joachim Tuchel          [hidden email]
Fliederweg 1                         http://www.objektfabrik.de
D-71640 Ludwigsburg                  http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0         Fax: +49 7141 56 10 86 1

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

That idea of using a WATask to be #renderOn: instead of #call: is a contradiction.

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

That idea of using a WATask to be #renderOn: instead of #call: is a contradiction.

hmm. I am not sure about that. The usefulness of WATask gets very limited once it is embedded in another Components, because you can always click somewhere else and bypass the WATask completely.

But still you can use a WATask to ensure a certain sequence of actions/events.

In any case, when they answer you know they did because you’ll see control on whatever you did to capture its answer (and the actions of the code after that)

That is not true. If you don't register an answerHandler for a WATask, you won't know at all. What you say is only true if you call: ed it  which Mariano didn't.

But I guess in the end we both mean the same thing: you have to think carefully if a WATask is as safe in your special case as you learned it would be. In the good old Sushi store, it was very helpful, because it "was" the main component and not embedded in otrher Components that have their own callbacks and such.



Joachim

-- 
-----------------------------------------------------------------------
Objektfabrik Joachim Tuchel          [hidden email]
Fliederweg 1                         http://www.objektfabrik.de
D-71640 Ludwigsburg                  http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0         Fax: +49 7141 56 10 86 1

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