<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
</head>
<body class='hmmessage'>
Could you try emulating a WATask type thing with ajax?<div><br></div><div>For example... re-render an element on the page with the component you want to call, and have that component return a script based on what happens to itself. So, if you would normally be answering true, return the old component, or, if answering false, either do nothing or re-render itself.</div><div><br></div><div>Hope that helps</div><div>RS</div><div><span class="Apple-tab-span" style="white-space:pre">        </span></div><div><div><br>> From: jfitzell@gmail.com<br>> Date: Sat, 31 Jul 2010 14:30:11 +0100<br>> Subject: Re: [Seaside] Comet and #call:<br>> To: seaside@lists.squeakfoundation.org<br>> <br>> I'm afraid I don't really understand the semantics you are trying to<br>> achieve. But yes, obviously any response you return will replace the<br>> whole page. If you don't want the browser to replace the page, I know<br>> of no solution other than using Ajax.<br>> <br>> It would be quite straightforward to have a callback that does a<br>> #show: and then returns just the new component's HTML for the JS to<br>> put in the DOM. But you have to know where to put it in the DOM. This<br>> isn't too hard if you're doing it on a case by case basis, but I'm not<br>> sure how you would do it easily in a generic way.<br>> <br>> There's no good documentation of the render loop (which I think is<br>> what you're asking about). I discussed it a bit in my talk at ESUG in<br>> 2008 and the slides are available online, but I don't think they'd be<br>> much help really. The concept is quite simple though: there are two<br>> subclasses, one which processes callbacks and one which renders the<br>> page. Each does its work and invokes an instance of the other,<br>> creating a loop.<br>> <br>> Julian<br>> <br>> On Fri, Jul 30, 2010 at 4:41 PM, andres <andres@lifia.info.unlp.edu.ar> wrote:<br>> > Hi Julian, thanks for the response. I tried working with "self session<br>> > returnResponse:" but the problem remains since the response I send replaces<br>> > the whole page. I guess that if that behaviour is wired in the render loop I<br>> > would need to go deeper and somehow change the way callbacks are handled. I<br>> > am thinking two alternatives here:<br>> ><br>> > 1. Create a new call mechanism that somehow cancels the response, so that<br>> > the web client stays unaltered (is this possible?). Then push the page via<br>> > comet to update the required id. The question here is: can I cancel the<br>> > response but let the continuation keep its flow?<br>> ><br>> > 2. Use an ajax update, which works ok from the rendering point of view and<br>> > emulate the continuation flow. Can this be done? Is something in Seaside as<br>> > "forking" a new continuation (like a child process)?<br>> ><br>> > Also, could you recommend any readings on seaside internals to understand<br>> > how the control loop works? Again, any hints are much appreciated!<br>> ><br>> > Best regards,<br>> > Andrés<br>> ><br>> > Julian Fitzell escribió:<br>> >><br>> >> That's because the Render Loop, after processing callbacks, then<br>> >> returns the rendered page as the response. If you want to return<br>> >> something else, either you don't want to be using the Render Loop, or<br>> >> you need to manually return a response in the callback (in 2.8: "self<br>> >> session returnResponse: ..."<br>> >><br>> >> On Thu, Jul 29, 2010 at 10:01 PM, andres <andres@lifia.info.unlp.edu.ar><br>> >> wrote:<br>> >>><br>> >>> I guess I must be missing something because I see no difference between<br>> >>> #call: and #show:, except for the fact that #call blocks and #show does<br>> >>> not.<br>> >>><br>> >>> When I do<br>> >>><br>> >>> MyApp>>...<br>> >>> self<br>> >>> update: #componentPane<br>> >>> with: Component1 new.<br>> >>><br>> >>> The network traces in firebug shows that only the required resources for<br>> >>> Component1 are requested to the server. On the other hand when I hit the<br>> >>> link rendered by:<br>> >>><br>> >>> Component1>>renderContentOn: hmtl<br>> >>><br>> >>> html anchor<br>> >>> callback: [self show: Component2 new];<br>> >>> with: 'A call'.<br>> >>><br>> >>> firebug shows that everything that belongs to the page is requested again<br>> >>> to<br>> >>> the server (all the .css, .js, etc).<br>> >>><br>> >>> Thanks,<br>> >>> Andrés<br>> >>><br>> >>><br>> >>> Lukas Renggli escribió:<br>> >>>>><br>> >>>>> code in WAComponent>>call: without any luck :(. So, do you think this<br>> >>>>> can<br>> >>>>> be<br>> >>>>> done? Am I missing something important about the way Seaside works? Any<br>> >>>>> hints are very much appreciated!<br>> >>>><br>> >>>> Did you look at #show:/#show:onAnswer:? This is the #call:/#answer:<br>> >>>> without continuations and without the forced full-page refresh.<br>> >>>><br>> >>>> Lukas<br>> >>>><br>> >>> _______________________________________________<br>> >>> seaside mailing list<br>> >>> seaside@lists.squeakfoundation.org<br>> >>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside<br>> >>><br>> >> _______________________________________________<br>> >> seaside mailing list<br>> >> seaside@lists.squeakfoundation.org<br>> >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside<br>> >><br>> > _______________________________________________<br>> > seaside mailing list<br>> > seaside@lists.squeakfoundation.org<br>> > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside<br>> ><br>> _______________________________________________<br>> seaside mailing list<br>> seaside@lists.squeakfoundation.org<br>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside<br></div></div>                                            </body>
</html>