"Lukas Renggli" <
[hidden email]> 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
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Locked
