[Seaside] Comet and #call:
andres at lifia.info.unlp.edu.ar
Wed Aug 4 21:54:34 UTC 2010
thanks for your response; I've tried your example but It
doesn't quite fit my needs. I've been playing with different approaches
and I came to something that fits my needs, but I have no idea if this
may screw something in the underlying page flow. I've trying to adapt
#call: to what I need, but I did this quite intuitively since I still
don't know how the underlying continuation mechanism works in Seaside.
This is what I've got so far:
with: [html anchor
onClick: (html request callback: [Transcript print: (self myCall: C2
| value |
value:=self myPrimCall: aComponent. "This call is blocking"
self push: self into: 'contents'. "This uses comet to render a
component into a div. After myCall returns we replace the div contents
to show self again"
self push: aComponent into: 'contents'. "Push aComponent render result
into the div"
^Seaside.AnswerContinuation currentDo: [ :cc | | event |
event := nil.
event := aComponent onAnswer: [ :value |
cc value: value.].
onClick: (html request callback: [self answer: 34]);
with: 'Answer link'
This seems to work ok in the following aspects:
1. The #call: / #answer: works ok. The 34 is not print on the transcript
until I click on the 'Answer link' anchor. Also, if I remove the
"Seaside.WARenderNotification raiseSignal" then #myCall: becomes
non-blocking (which seems to be ok regarding the differences between
#call: and #show:).
2. According to firebug only the resources needed for C2 are requested
from the server when executing myCall: C2 new (and the same happens when
answering from C2 and showing again C1).
Do you think this can lead to breaking things in Seaside?
Thanks in advance,
Julian Fitzell escribió:
> On Mon, Aug 2, 2010 at 3:01 PM, andres <andres at lifia.info.unlp.edu.ar> wrote:
>> Hi Julian,
>>> 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.
>> Could you give me a hint on how to do this? I.E. start the #call: process by
>> triggering the continuation step but avoiding the html response to reach the
>> browser? If that is possible I think I can handle the rest.
> Hi Andres,
> I guess you want to do something similar to following (untested). I do
> think you'll run into trouble later figuring out what to return in the
> generic case and where to put the returned content in the browser, but
> I'll be interested to hear how far you get.
> renderContentOn: html
> html anchor
> callback: [ self showAndRespondWith: someComponent ];
> with: 'link'
> showAndResponseWith: aComponent
> self show: aComponent.
> self requestContext respond: [ :response |
> contentType: WAMimeType textHtml;
> nextPutAll: (aComponent rendererClass builder render: aComponent) ]
> seaside mailing list
> seaside at lists.squeakfoundation.org
More information about the seaside