[Bese-devel] UCW Ajax branch polling/asynch updates

[Attila Lendvai]

>
> I noticed the recent check-ins by Attila to enable dirty component
> tracking which should allow for asynchronous updates.  The polling
> script is only enabled for single-frame-applications and I'm having a
> devil of a time understanding how this is intended to be used, the
> implications of a single-frame application and what the interface is for
> informing UCW that one of the components has had an asynchronous content
> update.


ok, for the first part i have no useful answer: this is the state of the
code. i wanted to get rid of backtracking (in short: speed, per session
memory leaking, and ajax apps can have much better navigation then the
loosey back button). so i've added the single-frame-application-mixin that
achives this.

then i added some features (polling) that is only useful/interpretable with
ajax apps and it ended up hooked on s-f-a-m. there's a lot to be cleaned up
in the way sfam/ajax is integrating into the rest of ucw. it's even possible
to mix backtracking/back button with ajax stuff, but i don't really
understand how that should work. so for now (and maybe for a long time) ajax
apps are like a remote desktop connection to the server. if you press the
back button you are looking at the past, that is out of sync. pressing
something will most probably end  up in a redraw of the screen, just like
the refresh button of your browser.

you should inherit sfam, and then you get the polling support and lose
backtracking. then you have a few methods you can specialize on (this is
also young code, so don't expect a cristal-clear interface here):

   - (notify-session-event session) to wake up a session poller. iow,
   tell ucw you have stuff for the client.
   - (has-events-for-the-client session) to customize the check for
   actual events (you (the poller) may be woken up without actual events). the
   default implementation only checks for dirty components in the session.
   - (send-events-to-the-client session) to actually implement sending
   stuff to the client. the default impl is empty, this is a small anomaly in
   the code. dirty components are implicitly sent at the end of the ajax
   answers for now. this is a TODO entry to move it here... you can also add
   your custom stuff here, but rendering xml to the yaclml-steam from an ajax
   action body is way much simpler.

and finally take a look at the shared-counter example. it demonstrates
nearly all of this.

I have an application I'd love to put together with UCW, but it requires
> the ability to perform frequent updating of the client UI based on
> background server processes.  Any help/insight would be appreciated.


hope the above helps.

I've also noticed that the current repository state seems to not handle
> the back button and refresh buttons properly.  The isolation counter
> example is definitely not behaving correctly on either refresh or back
> button (refresh always resets all counters to 0) and I'm seeing funny
> behaviors with my current application.  I can provide further details if
> this is not a known problem -- or perhaps is a result of my
> unfamiliarity with some of the new functionality in the ajax branch.


i've deleted some superfluous disallow-response-caching calls that may have
caused some confusion. also added some more description to the example page.
after the fix and some clicking it seemed to be behaving as expected, but it
even fooled me once to think it's broken... :)

anyway, if you find unexpected things to happen after the update, feel free
to ask.

-- 
- attila

"- The truth is that I've been too considerate, and so became
unintentionally cruel...
- I understand.
- No, you don't understand! We don't speak the same language!"
(Ingmar Bergman - Smultronstället)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/bese-devel/attachments/20061021/e4a0be92/attachment.html>