Vyacheslav Akhmechet <[email protected]> writes: > Could you give a quick summary of how the new navigation works and > what changes you've made? There is a long thead about it, but > understanding the big picture involves understanding the whole > discussion now, and a quick summary of what came out of it would be > very useful.
Sure. Please forgive my copy/pasting from that thread, some passages are relevant, so I recap them here: The navigation-rewrite topic branch contains a significant rewrite of the whole navigation and dispatching system in weblocks, as well as a number of related improvements, that are only possible because of the rewrite. The tree may be viewed at http://github.com/jwr/weblocks-jwr/tree/navigation-rewrite Overall, the rewrite resulted in less code and a smaller number of concepts, which I'm very happy about. Major features: -- navigation items can have URIs different from their names -- you can now have hidden navigation items -- you can render navigation content separately from the menu (teleport hack) -- generalized tree walking (see walk-widget-tree) -- tree walking now tracks depth (necessary for the next feature) -- ability to set the page title and breadcumbs name from anywhere in the tree ("most specific widget" gets to do that) -- breadcrumbs widget (You are here: Home > Users > All Users) -- container and composite are gone, use (make-instance 'widget :children (list...)) -- root-composite is now root-widget -- dispatcher is gone, subclass selector and define get-widget-for-tokens -- *uri-tokens* is now an object -- you can't (setf widget-children) anymore, see set-children-of-type -- anyone who uses set-children-of-type can participate in flows as a parent -- new render-widget-children method for additional rendering flexibility -- lazy-navigation: acts just like navigation, except that instead of passing widgets to it you may pass functions (closures). These will be called when the navigation panes are actually selected and should return widgets. That way you avoid creating the entire widget tree when the session is initialized, so you get a quicker response time initially and don't waste resources on things the user may never get to. For larger sites this could be quite important. -- there is one make-widget-place-writer function which will work for everyone that maintains their children using set-children-of-type. >From the design point of view: -- the widget tree is walked twice: once to update, once to render -- the second rendering pass should be side-effect free -- dispatcher, composite, container are gone -- look at get-widget-for-tokens to see how dispatching is done -- selector is the key to selecting parts of the tree based on something (e.g. URIs) -- static-selector specifically implements selecting based on URIs -- navigation implements, well, navigation, which is basically static-selector functionality with human-readable names for items -- dynamic dispatching with caching is done by on-demand selector A quick guide to updating your code: -- replace (root-composite) with (root-widget) -- replace (make-instance 'composite :children XXX) with (make-instance 'widget :children XXX) -- replace (setf (widget-children XXX) YYY) with (set-children-of-type XXX YYY :your-type) -- replace (composite-widgets XXX) with (get-children-of-type XXX :your-type) -- adapt your make-navigation calls to the new interface -- if you have used on-dispatch, you want (make-instance 'on-demand-selector :lookup-function #'your-lookup-function) where your-lookup-function takes a selector object and tokens (the selector is usually ignored) and returns three values: widget or nil, consumed tokens, remaining tokens. I think that can serve as a quick guide. I've included extensive docstrings (look in selector.lisp for example), so that should help. There are no tests. I do feel bad about it, but it isn't likely I'll be implementing them anytime soon. This work has not been merged yet, and I believe there is still disagreement as to whether set-children-of-type is a good idea. See the thread for detailed discussion. Having considered it somewhat more, I still think it is the right approach for a mutable widget tree framework that weblocks is. I would not choose this approach for a purely functional web framework. --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 -~----------~----~----~----~------~----~------~--~---
