[Seaside] Asynchronous message sending and Comet
Rob Withers
reefedjib at gmail.com
Wed Sep 29 11:44:56 UTC 2010
I worried about that. Thanks.
--------------------------------------------------
From: "Lukas Renggli" <renggli at gmail.com>
Sent: Wednesday, September 29, 2010 6:14 AM
To: "Seaside - general discussion" <seaside at lists.squeakfoundation.org>
Subject: Re: [Seaside] Asynchronous message sending and Comet
> You mail is too long ...
>
>> "GRError: You can only #call: and #answer: from within a callback or a
>> Task"
>
> Try with the non-blocking #show:, see
> http://book.seaside.st/book/components/calling/show-answer.
>
> Lukas
>
> On 29 September 2010 11:48, Rob Withers <reefedjib at gmail.com> wrote:
>> bump. Can someone help me with this question, please?
>>
>> --------------------------------------------------
>> From: "Rob Withers" <reefedjib at gmail.com>
>> Sent: Saturday, September 25, 2010 3:31 PM
>> To: "Seaside - general discussion" <seaside at lists.squeakfoundation.org>
>> Subject: Re: [Seaside] Asynchronous message sending and Comet
>>
>>> I am working my way to building the Login/Register/ChangePassword/Home
>>> components of my app and navigating between them. There are
>>> asynchronous
>>> messages being used. I have an AccountManager instance, held by my
>>> session,
>>> which asynchronously talks to a SecureAccountManager in another image.
>>> This
>>> results in the following seaside callbacks not having an immediate
>>> answer
>>> from async api invocation.
>>>
>>> LoginComponent>>login calls #login: on the acctMgr. On success it
>>> expects
>>> to go to the HomeComponent. On failure it shows its page with an error
>>> message.
>>>
>>> RegisterComponent>>registerUser calls registerAccount: on the acctMgr.
>>> On
>>> success it expects to go to the HomeComponent. On failure it shows its
>>> page
>>> with an error message.
>>>
>>> ChangePasswordComponent>>changePassword calls changePassword: on the
>>> acctMgr. On success it expects to go to the HomeComponent. On failure
>>> it
>>> shows its page with an error message.
>>>
>>> My code looks like the following such that the callbacks I am
>>> registering
>>> for dealing with the asynchronous messaging get called after control
>>> leaves
>>> the Seaside callback.
>>>
>>> (self session login: self credentials)
>>> whenResolved: [:acct | self answer: acct];
>>> whenBroken: [:msg | self loginFailed].
>>>
>>>
>>> When I run the Register and then Login callbacks, I get the following
>>> error:
>>>
>>> "GRError: You can only #call: and #answer: from within a callback or a
>>> Task"
>>>
>>> Sorry for the long lead up...I am definitely outside of a callback flow
>>> of
>>> control, or a Task flow of control. In otherwords I am outside of the
>>> HTTP
>>> request/response cycle.
>>>
>>> So I need to use Comet. It seems easy enough, but I am confused.
>>>
>>> Let's continue with my LoginComponent (presumably the same would be done
>>> to other Components).
>>>
>>> In its renderContentOn: html, I need to add the following:
>>>
>>> LoginComponent>>renderContentOn: html
>>>
>>> html div
>>> id: 'login';
>>> class: 'generic';
>>> with: [...];
>>> html script: (html comet
>>> pusher: self class pusher;
>>> connect)
>>>
>>> I gave the div an id and I installed and connected a comet script.
>>>
>>> Later, when my async reply comes in, I call a method update
>>>
>>> LoginComponent>>update
>>>
>>> self class pusher javascript: [:script |
>>> script element
>>> id: 'login';
>>> update: ????].
>>>
>>> My question concerns what I should update with (where the ???? is). To
>>> complicate matters, I want to do two different things depending on
>>> success
>>> or failure of my code. On success, I want to switch to a different
>>> component. Without asynchrony I would send "answer: acct". Is this
>>> possible in a comet script? I want the other component to have
>>> control/be
>>> the active component (I am not sure how to describe this. When a
>>> component
>>> sends #call: with another component, he is switching control to that
>>> component, right?). On failure, I want to refresh the error message (it
>>> may
>>> not be displayed...) showing login failed, but leaving the
>>> LoginComponent as
>>> the active component.
>>>
>>> How can I go about doing these things?
>>>
>>> Many thanks!
>>> Rob
>>>
>>> --------------------------------------------------
>>> From: "Rob Withers" <reefedjib at gmail.com>
>>> Sent: Monday, September 20, 2010 7:21 PM
>>> To: "Seaside - general discussion" <seaside at lists.squeakfoundation.org>
>>> Subject: Re: [Seaside] Asynchronous message sending
>>> andSeaside/Script.aculo.us/JavaScript/AJAX
>>>
>>>> Thanks for pointing this out, Lukas. I have a lot to learn with
>>>> Seaside,
>>>> and am now just reading the book. I noticed there is a section on
>>>> Comet,
>>>> which I read. It is good to know that async events can update the
>>>> page.
>>>>
>>>> Cheers,
>>>> Rob
>>>>
>>>> --------------------------------------------------
>>>> From: "Lukas Renggli" <renggli at gmail.com>
>>>> Sent: Monday, September 20, 2010 11:47 AM
>>>> To: "Seaside - general discussion" <seaside at lists.squeakfoundation.org>
>>>> Subject: Re: [Seaside] Asynchronous message sending
>>>> andSeaside/Script.aculo.us/JavaScript/AJAX
>>>>
>>>>>> I am trying to figure out how I can integrate my asynchronous message
>>>>>> sending framework with Seaside. From my reading, it seems that
>>>>>> Seaside
>>>>>> works on a request/response model. Furthermore, with
>>>>>> JavaScript/AJAX/Script.aculo.us it still works on a request/response
>>>>>> model.
>>>>>
>>>>> Yes, this is how HTTP is designed.
>>>>>
>>>>>> There seems there is no way to "push" events/content. Is this
>>>>>> accurate?
>>>>>
>>>>> No.
>>>>>
>>>>> For a long time there is the Comet package that provides a "hack" for
>>>>> pushing events from the server to the client. See the Comet examples
>>>>> that come with every Seaside distribution.
>>>>>
>>>>> Also Philippe recently published a WebSocket implementation for
>>>>> Seaside, but that doesn't work with all web browsers yet.
>>>>>
>>>>> Lukas
>>>>>
>>>>> --
>>>>> Lukas Renggli
>>>>> www.lukas-renggli.ch
>>>>> _______________________________________________
>>>>> 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
>>
>
>
>
> --
> Lukas Renggli
> www.lukas-renggli.ch
> _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
More information about the seaside
mailing list