Stephen Compall <[email protected]> writes: > Cherry details: I skipped the modern-dispatching, presentation-dom-id, > and label for=id changes, because the first are part of nav4 and will be > merged with it, and the others break a bunch of tests (and should be > merged from Jan's hg repo on Bitbucket anyway). Jan, please take a look > at the descendants of your cherried changes I created in dev. > > template-block is a widget for html-template. It uses > asdf-system-connections, so we didn't grow the dependencies; if you want > to use it, load asdf-system-connections before loading anything else, > then arrange for both Weblocks and html-template to be loaded. > > The other stuff is pretty much as it was in weblocks-jwr. If I hadn't > put h1 {display:none} in hfsbo.com everywhere already, I would probably > put the caption hiding bit to use right away. In other areas, I did > immediately put the dataform exposure stuff to use right away to fix > some UI problems there, so thanks for that.
Cool! I will look at the descendants once I find a moment. As to navigation-rewrite branch (not sure if that is what you meant), this is still a work in progress. I use it and I'm very happy with it (it does all I need, and I do make heavy use of multi-level navigation with multiple dispatching functions as well), but I find that things can still be simplified. Today I managed to rip out container and composite altogether, along with all their supporting machinery. Turns out they were just artificial constructs, complicating things. The only cost is an extra slot in widget and a change in the rendering protocol (I introduced an extra render-widget-children GF). Right now all widgets may have children and root-composite became root-widget. I'll push changesets to github tomorrow. I think the only remaining work to be done in the navigation-rewrite branch is to cleanly implement tree walking, based on your suggestions. I also want to introduce a documented tree protocol, so that people know where to hook things -- for example, the breadcrumbs widget needs to walk the widget tree after it has been shaken down, e.g. after all widgets have determined their children, but preferably before rendering. After I finish that, the branch will be ready for merging, if anybody would like to. --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 -~----------~----~----~----~------~----~------~--~---
