Ok, I have the first cut of the new nav design, it works for my application so far. Dynamic wiki-style on-demand navigation is untested.
It turns out Stephen was right being suspicious about the dispatcher (Stephen, thanks for your comments!). In my design the dispatcher is gone, so is selector-mixin. A rough diagram of what things look like is here: http://screech.rychter.com/files/weblocks-new-nav-design-20081214-2.pdf Major points: * The dispatcher is gone, so is selector-mixin, and so is the whole pane-info structure business along with its canonicalization. * wiki-style navigation is done by on-demand-selector * We get a fairly simple static-selector which will likely work for 99% of all dispatching needs and won't force people to write their own token-processing functions. Utility function for creating this selector will be coming soon. * As a bonus, I wrote a simple breadcrumbs widget that shows the current position within the navigation tree. * A navigation where you can separate the menu from the content should be easy to implement and I'll likely do it over the next day or two. * The make-navigation interface will certainly change to something more useful. In particular, hidden menu items will be supported and the syntax will be more sane. As for now, if you'd like to test, please use (make-navigation "Name" (list "Item Name" (make-widget blah blah) "item-uri") (list "Item Name2" (make-widget blah blah) "item-uri2")) Since I found working with multiple hg branches on bitbucket troublesome, I forked the repository (sorry about that, but I have deadlines to meet). You can find it on github at http://github.com/jwr/weblocks-jwr/tree/weblocks-jwr Note there are multiple branches there -- weblocks-jwr is really a merge between some things from modern-navigation and weblocks-dev. The yui branch contains my (limited) YUI stuff, and the navigation-rewrite branch contains the navigation work. I intend to work with small, contained topic branches, as I find this works much better than huge long-lived mega-branches which later cause mega-merges. The code I wrote about above is in the navigation-rewrite branch on github. I will be pushing to it regularly as I develop from now on. Comments very welcome. --J. PS: I know that a description of my git workflow might be useful for some of you: What I do locally isn't complicated and works very well: 1. I develop on a branch called 'jwr' that gets rebased all the time on top of pretty much everything else (weblocks-jwr, yui, and a bunch of other local topic branches). I commit everything here. 2. From time to time, I check out 'weblocks-jwr', 'yui', or other branches that I push to github and "git cherry-pick" the changes from 'jwr' that I think make sense for weblocks or yui. 3. From time to time, I 'git push github' which syncs weblocks-jwr and yui branches with those on github. It also syncs any other branches that I ever pushed to github automatically. So, github will end up with my public branches, while my private branches stay private. 4. Go back to step 1. The nice thing about this is that git notices the changesets that were cherry-picked into another branch and just silently reorders things. I don't get conflicts or even warnings about duplicate changesets. This is beautiful. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
