[Seaside] Seaside + Comet

Esteban Robles Luna esteban.roblesluna at gmail.com
Fri Jan 19 22:29:32 UTC 2007

Thanks for your replay Lukas!

On 1/19/07, Lukas Renggli <renggli at gmail.com> wrote:
> > I`m a newbie with seaside and comet. After loading successfully
> > SeasideComent on VW, I looked at the examples of Comet.
> > In the counter example we can see these code:
> >
> >         pusher javascript: (SUElement new
> >                 id: 'count';
> >                 update: self count contents asString)
> >
> > The update method receives a string to be updated in the page. I`m
> > trying to reproduce the renderOn: behaviour of a SUComponent so that
> > the string to be pushed is a result of the rendering process.
> SUElement has that already. Try something like:
> pusher javascript: (html element
>      id: 'count';
>      render: [ :r | r anchor callback: [ ... ]; with: ... ])

The problem is that html is undefined in my context. May be what I`m
trying to reproduce is somewhat complicated. I`m going to explain it
more precesily:
* I have a component that understands renderOn:
* Also the component has a pusher for updating itself.
* I have a process that periodically (5 seconds) sends an update
message to the component.

I want to reuse the renderOn: behaviour. For example the update
message to the component don`t have a reference to the render, so my
problem is to get a render in order to use the renderOn message.
How do I get the render in that context? is it possible?

> > The problem is that the updater is not working after the re-rendering.
> > I supposed that the problem is with the push-like code. Is there a
> > solution for using comet and the renderOn: transparently?
> I don't exactly understand what you are trying to do. If you push code
> containing callbacks, then all the connected sessions will receive
> exactly the same string. This means all the callbacks will point (and
> be evaluated) in the session that did the rendering. Moreover people
> will be able to hijack the initiating session, as you just hand out
> your private key to everybody. I don't think you want that, but
> unfortunately this cannot be avoided easily.
> What I suggest you to do is to just trigger an event handler in all
> your clients so that they can make an update request on their specific
> session.
> Was this what you wanted to do?
> Cheers,
> Lukas
> --
> Lukas Renggli
> http://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