[Seaside] Session/component sharing

Robert Krahn robert.krahn at student.hpi.uni-potsdam.de
Tue Oct 9 12:48:37 UTC 2007


Hello Sebastian,

now I get your point. Thank you for the explanation.

The thing I don't know to achieve is how a component (acting as a  
presenter/controller) can update the view when the model is changed.  
The component can of course also take the role of a observer. But  
after the model sent the update message the view in the browser must  
somehow be rendered again (I am aware of the fact that this is not  
the usual functionality).

How can such behavior be triggered?

Best regards,
Robert

Am 08.10.2007 um 20:00 schrieb Sebastian Sastre:

> Normally AJAX allows client-server interaction in a kind of half  
> duplex
> fashion. Comet, the reference that What Lukas passed to you as  
> reference
> will allow you to make a full duplex comunication between clients.  
> I don't
> know how mature comet is for seaside nor how secure it is.
>
> What I said to you it's about having decoupled the model domain  
> from the
> application domain. MVC and MVP (Model View Controller and Model View
> Presenter) are "frameworks" that used to help to maintain decoupled  
> the
> observations of the model. This is a very commmon thing in  
> smalltalk I don't
> know how familiarized with that you are but for your question I'll  
> suggest
> to read a little about them at least to get the idea.
>
> Components can "look" a common model when they should render  
> something that
> is sharing a model without sharing the observation (each session  
> will make
> it's own instances of the components that produce observation of  
> the model).
>
> You can make a model (an object graph) that is not aware that is being
> observed by seaside compoenets at all. See:
>
> 	CounterModel>>plusOne
> 		count := count + 1
>
> That's the model (a graph of only one object but could be the model  
> of an
> entre company) made singleton for simplified persistance or  
> retrieved from
> your favorite persistence mechanism.
>
> CounterPresenter>>counter
> 	"Returns the instance of the receiver."
> 	^ CounterModel instance
> 	
> CounterPresenter>>increment
> 	"Makes the receiver to increment one."
> 	self counter plusOne
>
> CounterPresenter>>renderContentOn: html
> 	"Renders the receiver in the html canvas"
>
> 	html paragraph: self counter count.
>
> 	html anchor
> 		callback:[self increment];
> 		text: '+'.
>
> 	
> If CounterModel>>instance returns the common model, then any number of
> sessions rendering CounterPresenters will observe (and affect) that  
> same
> model.
>
>
> Sebastian Sastre
> PS: as you can see there is no global (beside the class names)
>
>> -----Mensaje original-----
>> De: seaside-bounces at lists.squeakfoundation.org
>> [mailto:seaside-bounces at lists.squeakfoundation.org] En nombre
>> de Robert Krahn
>> Enviado el: Lunes, 08 de Octubre de 2007 12:13
>> Para: Seaside - general discussion
>> Asunto: Re: [Seaside] Session/component sharing
>>
>>
>> Am 08.10.2007 um 15:44 schrieb Lukas Renggli:
>>> Have a look at the comet package in the Seaside repository.
>>
>> Great, this is what I was looking for :-)
>>
>>
>> Am 08.10.2007 um 14:59 schrieb Sebastian Sastre:
>>> Why you wish to share the view when you can share the
>> model? You can't
>>> make everybody to have it's own observation of it?
>>
>> Sorry, I don't know if I understand your question. How can I
>> share the model between different users/browsers? Maybe with
>> class variables as global state?
>> _______________________________________________
>> 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



More information about the seaside mailing list