[Seaside] Comet and #call:

[Robert Sirois]

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