Stephen Compall <[email protected]> writes:

> Jan Rychter <[email protected]> writes:
>> In particular, if you think about how the current navigation works, you
>> realize that it has serious limitations -- for example, it uses dynamic
>> variables
>
> This is a manifestation of using CUC and CUDC.  Eliminating these solves
> the problem, by letting you pass a closure to WALK-WIDGETS or something
> instead of just plonking a hodgepodge of methods onto a GF and hoping
> the others cooperate.

Here's a progress report (detailed changesets are at
http://github.com/jwr/weblocks-jwr/tree/navigation-rewrite):

-- killed container-update-direct-children and container-update-children
-- introduced a walk-widget-tree method
-- killed *current-navigation-url*, widget-uri-path (formerly
   widget-current-navigation-url), *uri-tokens-fully-consumed*
-- *uri-tokens* is now an object that holds all tokens, remaining
   tokens, consumed tokens, and has a bunch of methods implemented.
-- only selectors now know their base-uri, because only they can
   meaningfully relate to it in any way

The hodgepodge of methods you refer to is something I'd call a protocol
and I believe is still required to a certain extent. For example, here's
what gets called when handling requests:

(defun update-widget-tree ()
  (walk-widget-tree (root-composite) #'update-children))

Those widgets that wish to dynamically update their children will
implement the method. For the moment, all selectors do so. I do not
think a method is a bad solution here. Even if you want to juggle your
children without holding them in a slot somewhere, you should let others
store them and update as needed.

And really, update-children could be called
modify-state-based-on-uri-tokens, because that's really what it is
supposed to do.

The jury is still out on the container.

This is all a work in progress, e.g. it will most certainly change.

--J.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"weblocks" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/weblocks?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to