[Bese-devel] Follow up to "New tutorial typos"

[Drew Crampsie]

2009/3/8 szergling <senatorzergling at gmail.com>:
> On Wed, Mar 4, 2009 at 1:41 PM,  <burban at opopop.net> wrote:
>> szergling <senatorzergling at gmail.com> writes:
>
> [...]
>
>>> Now, I am also confused about another thing. Suppose a component
>>> displays an action that does not 'answer', but has side-effects
>>> instead. I'm not sure why this action would repeatedly get called even
>>> when the component display is only refreshed and not clicked on.
>>>
>>> Here is a simple example to illustrate:
>>>
>>> (defcomponent refresh-demo ()
>>>   ((value :initform 0
>>>           :accessor component-value)))
>>
>> Add slot option ":backtrack t" for value.
>
> Ahh, that works now. And I was only trying to understand that myself
> with my frame & backtracking illustration (in the same post!). I
> thought I did try the :backtrack option, or perhaps it was :component,
> but that might have been too late in the night.

I have to note here that even with :backtracking T, the action itself
is still again run. This always happens. Backtracking works by
re-instating the value of any backtracked places before running the
callbacks and actions again. The behavior, like everything else in
UCW, is extensible (we've been talking about isolated frames as well,
there are some good use cases).

There is no way, without using HTTP, to distinguish between a link
being clicked and a link being re-loaded. UCW offers 'action
isolation', so that a particular action will only run once. UCW-AJAX
offered 'invocation isolated', the would re-run the action if it was
clicked again, but not if it was reloaded. This naturally requires
javascript. I'd love to see someone port the ucw-ajax components to
-core so we could play with this stuff.

>> Well, time for a new chapter of the tutorial "backtracking":)
>
> How was my tree diagram for a start? Comes complete with a "gotcha"! :D

I liked the tree diagram a lot! The actual tree structure will become
more explicit in a later revision, as i'm adding parent->children and
child->parent links to frames (via frame-ids) in order to support a
frame garbage collector that has better heuristics than the queue we
use now.

Even without :backtracking the tree structure does accurately
represent the various frames used. The nasty part is that the value
displayed on the page when a user hits 'back' might not be the value
stored somewhere in memory. Backtracking "solves" this problem, though
i find in practice it's rarely needed .. 'back' is not always 'undo'
in an application, and user expectations reflect this. backtracking,
for me, has mostly been replaced with isolated actions, and callbacks
and action that expect to be executed a number of times, and therefore
know that any data they access might have 'changed in the future'.

Regardless, the tree of frames diagram does accurately model a users
'path' through an application, and more importantly they are where we
store the callbacks and actions that really drive UCW. When a
particular UCW-generated URL is hit, the UCW dispatcher first extracts
the session, then the frame is found in the session. Assuming it finds
the frame (it may have expired), it reinstates the backtracks, it then
looks up the name of any GET or POST variables in the CALLBACKS store,
which lives in that particular frame. Any callbacks that are found are
FUNCALLED with the value of the HTTP variable. Once all  the callbacks
have been called, it find the ACTION in the ACTIONS store and funcalls
it.

Once all that is done, a new frame is created, and the toplevel
component is rendered withing the context of that new frame. UCW tags
that create actions and callbacks are run during the render cycle,
populating its action and callback stores, and the whole process
begins again.

At least that how it works by default. There are a number of excellent
use cases for not creating new frames, different forms of isolation,
etc etc, so all this is extremely extensible.

>Apologies if this seems like a rant. I'm frustrated. You don't even
>deserve this... it's not your fault.

Actually, it might be, as i'm one of the Adminstrators at cl-net, and
i control the domain and mail system... if you are losing mail that is
my fault! :).

Cheers,

drewc





>
> Thanks for the heads up!
>
> _______________________________________________
> bese-devel mailing list
> bese-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/bese-devel
>