Forum OpenACS Development: templated ad_context_bar
I've written a templated version of ad_context_bar because this seemed to be one of the few, commonly used functions left that violates the logic/layout split. It consists of a replacement function multirow_context_bar and an adp template and allows you to do something like:
# in your tcl file
multirow_context_bar context_bar [list [list "./" "Node1"] "Node2"]
<!-- in your adp file -->
<include src="path/context_bar" &context_bar="context_bar">
I was going to pull it out an submit it, but I'm not sure where it should go. The original ad_context_bar is in /packages/acs-tcl/tcl/navigation-procs.tcl - is this the best place for it? In which case should the template go in /packages/acs-tcl/templates/?navigation/?
Can the template not handle the standard list structure of ad_context_bar? It wont be as neat as using a multirow datasource, but it would mean that there wouldn't be a 5th version of the context_bar proc, and only a few templates, not every tcl page, would need to be updated to take advantage.
I guess there is no reason why ad_context_bar couldn't return an unmodified list of lists - which when passed to:
<include src="/packages/acs-subsite/www/context_bar" deprecated_ctx_bar="context_bar">
gets converted multirow and then handled by the same template as multirow_context_bar.
The packages would build their breadcrumbs but display format would be built by the master template.
In this way it would be easy to (say) supress the bold headers put out by packages by just ignoring them in the master template. Currently 4.x packages are as annoying in this regard as 3.x packages. We see clients asking for "tab-style" navigation and then at times want to get rid of the bold headers saying (for instance) "file storage" (because you have a tab that makes this obvious), and you have to edit a bazillion files to do this.
My comment is orthoganal to Lee's, i.e. having the context bar be separately templatable might be nice even if its put out by the master template.
But the motivation's similar, I think - we need to make changing the site-wide look-and-feel of standard page elements easier than it is now.
Lee ... I'm somewhat loath to accept new feature stuff in our current release cycle, in the interest of getting the thing out the door (as soon as the name discussion closes and we modify docs to reflect it I should be able to roll a beta and a couple of weeks later a "real" release).
So maybe we can hold off on this until we start our next development cycle?
Having each package specify the package specific part of the breadcrumb trail as before, but then passing it to the master template for display sounds like the right way to do it to me.
In general, having some agreement about which doc elements the site wide master template is responsible for, and which the package client pages are responsible for, is also an excellent idea.
Sounds like more work for the Clean Up Team! Which I'm happy to pitch in with. Having a solid, consistent core seems more satisfying to me than bolting on another gadget :)
It's no problem to hold off submissions til after the release - that way it's easier to see what direction people want to go with these kinds of decisions.
I imagined a master template that is used throughout the whole site by default unless overridden.
I imagined a way to set a template so that an entire area of the site would use that one.
- http://mysite/ - master template
- http://mysite/whatever - inherits master template
- http://mysite/whatever/whatever - inherits master template
- http://mysite/my_bowling_league_bboard/ - has special bowling league template set
- http://mysite/my_bowling_league_bboard/news/ - inherits special bowling league template
- http://mysite/news/ - inherits master template
Lee ... yeah, cleaning up the core will be rewarding work, that and coming up with a "best practices" guide for package implementors (and maybe an "unacceptable practices" guide :)
instantiation of a variety of site-wide navigation aids a developer
might want to build. For example, you should be able to use the
same information (about the navigation tree that's required for
the context bar) to generate a hierarchical pull-down or left-side
If what we end up with is some kind of a navigation
service-contract, then it might make sense to look at the degree
to which it could integrate with site-map. (I don't really fully get
site-map yet, but that may just be me being dense.) There
should be one central place that makes it easy and intuitive to
organize the site-wide (or sub-site-wide) navigation tree.
1. A SC-based navigation gizmo builder is called by the package's page scripts (vs. today's glued-in calls to ad_context_bar). It would default to today's ad_context_bar. Making this SC-based makes it easier to imagine gluing in different navigation gizmos into different subsites, for instance. One possible substitution would be an implementation tracking a *real* breadcrumb trail rather than the sitemap-derived navigation bar that's arbitrarily built today.
2. The returned gizmo is passed as a property up to the master template, along with some of the other stuff we're mentioning.
3. The master template massages the navigation gizmo into whatever format the site designer's looking for.
Where would the gismo get information about the site tree from?
If packages were to create their own master templates, even if they were just do-nothing stubs which passed properties on to the default master, then the look of individual package instances could be changed by placing an overiding package master template under the page root.
How you generate the data depends on your choice of implementation of the SC. So one implementation could behave the same as the current ad_context_bar (although "a supplemented list of link/node pairs" might be a better description of the SC in this case; ie. you allow the SC call to specify additional link/node pairs). Whereas another implementation generates pairs based on the actual route taken by the user.
In which case we would also want other kinds of SC for other kinds of data structure that hold navigation elements; eg. "a tree of link/node pairs". Or am I missing the point? :)
In reality, though, if you have tabbed or pulldown navigation this generally *augments* rather than replaces the breadcrumb navigation bar.
And things like pulldown navigation menus tend not to depend on the page itself but rather ... the subsite, maybe? So a way to build navigation menus and pass them to a master template would be useful but wouldn't need to be constructed by every package and page, would it? It could be generated by (say) tha subsite's master template script.
In which case the separate context bar concept remains a list always.
Of course a list is just a boring tree
That's true, although if a designer wanted to display a custom navigation element based on a context list they might be interested in ensuring that the data isn't a tree if the display code didn't know how to display a tree.
I agree that navigation menus would probably be best generated in the master template. I think we have identified one distinguishing characteristic in the service contracts of navigation elements; namely whether or not the caller can supplement the generated data with additional specific data.
I think in general having a small selection of navigation element service contracts which guarantee the data structure returned, for which the content could be generated in different, commonly used ways is a really useful idea.
Is anyone involved in this thread interested in sitting down to write an informal proposal for what page elements should be treated as properties to push up to the master when we clean things up? Header, context bar, footer ... what else?
At one point I think there was some stuff floating around the aD site on this subject, in fact IIRC (though I may not!) it was part of the original discussions on templating. I was actually surprised to see 4.x packages building their page elements explicitly because I thought that the plan was to use the templating system much as we're talking about here.
But I may be wrong, I may've been hallucinating.