[Seaside] Comet and #call:

andres andres at lifia.info.unlp.edu.ar
Wed Aug 4 21:54:34 UTC 2010


Hi Julian,
               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:

C1>>renderContentOn: html

html div
	id: 'contents';
	with: [html anchor
			onClick: (html request callback: [Transcript print: (self myCall: C2 
new)]);
			with: 'link'.
		].

C1>>myCall: aComponent

	| 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"
	^value.

C1>>myPrimCall: aComponent

	self push: aComponent into: 'contents'. "Push aComponent render result 
into the div"
	^Seaside.AnswerContinuation currentDo: [ :cc | | event |
										event := nil.
										event := aComponent onAnswer: [ :value |
																		event remove.
																		cc value: value.].
										Seaside.WARenderNotification raiseSignal.
										].

C1>>renderContentOn: html
	
	html anchor
			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,
Andrés


Julian Fitzell escribió:
> On Mon, Aug 2, 2010 at 3:01 PM, andres <andres at lifia.info.unlp.edu.ar> wrote:
>> Hi Julian,
>>
>>> [snip]
>>>
>>> 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.
> 
> Julian
> 
> renderContentOn: html
>   html anchor
>     callback: [ self showAndRespondWith: someComponent ];
>     with: 'link'
> 
> showAndResponseWith: aComponent
>   self show: aComponent.
>   self requestContext respond: [ :response |
>     response
>       contentType: WAMimeType textHtml;
>       nextPutAll: (aComponent rendererClass builder render: aComponent) ]
> _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
> 


More information about the seaside mailing list