[Seaside] Session/component sharing

[Sebastian Sastre]

Very good, that's where what I was saying about incompleteness of AJAX as
comunication mechanism and the Lukas comments comes to the subject.

Normal html is not a full duplex comunication. AJAX is a clever palliative
to add functionality that the protocol can't naturally have, but is also
incomplete. With ajax you're fine until you need badly to perfom any kind of
comunication in which the initiative of it should born in the server side.
In that "bag" enters the model changes that should trigger some info about
observers needing an update.

The only way I know to succesfully do that is with comet which is basically
another clever hack to html by streaming html in an open full duplex socket.
But before complicate more than you need I suggest to really convince
yourself about a real need of that feature. For instance.. A periodical
updater really can't achive your objetive?

	cheers,

Sebastian Sastre
PS: I don't have references of real world applications using comet and
seaside

> -----Mensaje original-----
> De: seaside-bounces at lists.squeakfoundation.org 
> [mailto:seaside-bounces at lists.squeakfoundation.org] En nombre 
> de Robert Krahn
> Enviado el: Martes, 09 de Octubre de 2007 09:49
> Para: Seaside - general discussion
> Asunto: Re: [Seaside] Session/component sharing
> 
> 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
> 
> _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside