[Seaside] Re: Multi-page updates : Comet? Asteroid? Others?
renggli at gmail.com
Mon Jan 7 07:10:27 UTC 2008
> Ah. My search for "Comet" on squeaksource only yields Asteroid. I now found
> the one you mean under Seaside. Perhaps the search on squeaksource should
> also search nested packages inside a top-level project like Seaside?
Also search the mailing-list for references.
> >> - Is it very complex to use?
> > Not really, I think. The examples are rather simple.
> I browsed the Chat example. Wow. Where do I get the "Streaming-server
> required", or is this an Apache-only setup?
Well, that's the drawback. You need to use WAListener, which has shown
to be slightly buggy in Seaside 2.8 (fixed in 2.9). Moreover due to
the nature of streaming, Comet doesn't work behind Apache (or any
other proxy I know of).
> Would your default recommendations be (b) and (e)?
It is all a bit abstract. All your suggestens make sense in one way or
the other. Some are more difficult to get right than others, so I
would pick an easy one (e.g. the tabs) over something more
> WAComponent subclass: #PagePart
> PagePart class>>on: aModel
> ^self new model: aModel
> PagePart>>model: aModel
> aModel on: ModelChangeAnnouncement
> do: [:ann | self markDirty].
> PagePart>>renderAnchorOn: html
> html anchor
> onClick: (html evaluator callback: [:s |
> model doClick.
> self refreshAllMarkedDirtyOn: s]);
> with: 'click'
> PagePart>>refreshAllMarkedDirtyOn: script
> self allDirtyDo: [:dirtyPart |
> dirtyPart updateYourself.
> script element id: dirtyPart id; update: dirtyPart]
> Where would you record the #markDirty list for #allDirtyDo? Just walk the
> component tree via #children from the Page?
Yeah, that seems to be reasonable. This should also avoid unnecessary
updates in dirty children or dirty components. What I would do
however, if possible in your application, is to do one single update
of <body> </body>. Thats ways easier than what you are doing now and
still feels like an AJAX app.
> I keep wanting a Page object,
> but don't know how to get access to it from a descendant PagePart. I am
> likely missing a better way.
You could store the root component in the session. This doesn't make
your components easy to reuse though.
More information about the seaside