[Seaside] Re: Multi-page updates : Comet? Asteroid? Others?

[itsme213]

"Lukas Renggli" <renggli at gmail.com> wrote in message
>> - Is Asteroid the starting point? other options?
> This is not Seaside based.

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?

>> - 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?

(Perhaps #renderChatPusherOn may be better called #renderChatPushListener?)

>> If I can limit to single-user/multi-page, am I better off building a 
>> richer
>> single page (panels, tabs etc.), rather than trying to manage multiple 
>> pages
>> that need to be sync'ed?
>
> I don't quite get your question.

Here are 3 scenarios; pardon me if too elementary:

Scenario I: 1 user, 1 page: Ajax can keep it completely current. If some 
operations require updates to many components in that one page, either
(a) collect those updates using model announcements on server that are 
grouped into the single client-triggered SU refresh; or
(b) do client-triggered full page replace.

Scenario II: 1 user, many pages: Ajax will not keep them current. Options:
(c) Manage multiple 'virtual' pages on a single html page, by embedding into 
that page multiple tabs, multiple panels, etc. one each for what would have 
been a separate page. Remain entirely Ajax at that page level.
(d) Server push with Comet (Comet is not multi-user specific, imo).
(e) (Your suggestion): periodical refresh.

Scenario III: Multiple users: just like the above, except
(a) is not an option; and
(e) probably not a good option if a collaborative app.

Would your default recommendations be (b) and (e)?

Would you recommend doing or avoiding (a), and correspondingly (c)? You had 
suggested something before, and I was trying to work through the detailed 
Hows. If you did it, would you do something like the following:

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? 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.

Sincerest Thanks - Sophie