Forum OpenACS Development: templated ad_context

Posted by Lee Denison on 02/19/02 01:50 PM

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/?

2: Response to templated ad_context_bar (response to 1)

Posted by Stephen . on 02/19/02 02:12 PM

You could register an adp tag, <contextbar>, and the location of the template file would be hidden. But how about placing the template in the packages/acs-subsite/www heirarchy so that each subsite can control layout independantly?

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.

3: Response to templated ad_context_bar (response to 1)

Posted by Lee Denison on 02/19/02 03:08 PM

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.

4: Response to templated ad_context_bar (response to 1)

Posted by Don Baccus on 02/19/02 08:39 PM

My thinking for "the next version" of OpenACS 4.x (i.e. not this release cycle) is that the context bar, along with the header and some other standard doc pieces, should be *properties* handled by the master template rather than by individual packages.

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?

5: Response to templated ad_context_bar (response to 1)

Posted by Lee Denison on 02/20/02 09:53 AM

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.

6: Response to templated ad_context_bar (response to 1)

Posted by David Walker on 02/20/02 04:14 PM

Let's see if my template ideas are in line.
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.

i.e

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

7: Response to templated ad_context_bar (response to 1)

Posted by Don Baccus on 02/20/02 07:34 PM

The templating system is meant to be general enough to handle this kind of scenario, yes.

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 :)

8: Response to templated ad_context_bar (response to 1)

Posted by Michael Feldstein on 02/20/02 07:50 PM

It might be helpful to think about the context bar as one
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
menu.

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.

9: Response to templated ad_context_bar (response to 1)

Posted by Don Baccus on 02/20/02 09:30 PM

Ben's already looked into stubbing in hooks for a service-contract based navigation gizmo. It would make replacing the current context bar semantics with something different much easier. This is a new wrinkle on what we're talking about, leading to a synthesized picture looking something like:

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.

10: Response to templated ad_context_bar (response to 1)

Posted by Michael Feldstein on 02/20/02 11:11 PM

Question, Don:

Where would the gismo get information about the site tree from?

11: Response to templated ad_context_bar (response to 1)

Posted by Don Baccus on 02/21/02 02:25 AM

The same place the "site map" page gets it, from the table that maintains the relationships between package instances, mount points, and URLs.

12: Response to templated ad_context_bar (response to 1)

Posted by Stephen . on 02/21/02 09:55 AM

The file system location of the default master template is set within a subsite's properties. To chage the look of the Main Subsite you should create a new master template and update the properties. To change the default look of all subsites you should edit the default master template.

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.

13: Response to templated ad_context_bar (response to 1)

Posted by Lee Denison on 02/21/02 10:49 AM

So if I'm understanding this correctly, the SC could be defined as something like "a list of link/node pairs". Then the master template that is displaying the list would always know what data structure it is going to get when it makes the SC call.

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? :)

14: Response to templated ad_context_bar (response to 1)

Posted by Don Baccus on 02/21/02 04:18 PM

No, that's more or less what I'm thinking. Of course a list is just a boring tree, so I suppose if one wanted to handle all possible navigation styles with a single service contract then returning a tree might be the thing to do.

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.

15: Response to templated ad_context_bar (response to 1)

Posted by Lee Denison on 02/21/02 07:49 PM

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.

16: Response to templated ad_context_bar (response to 1)

Posted by Don Baccus on 02/21/02 08:31 PM

Yes, the master template script handling such things needs to do some error checking. Indeed that's just one more argument supporting the notion of pushing common document elements up to the relevant master rather than have each page handle them as is done today.

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.

Forum OpenACS Development: templated ad_context_bar