[Seaside] Comet and #call:

[Julian Fitzell]

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
>