generalizing this. And I came up with a few ideas.
How about if a package could define the nodes that exist within that
package, called the intra-package nodes. For example, the bug tracker
would have the index page named "List"; the "One bug" node
corresponding to bug.tcl; the "New bug" node; the "Admin" node; the
"Admin : Versions" node; etc.
This sub-package site map would be specified somewhere in a .tcl file
that gets loaded at startup. Then instead of manually building the
context bar, the way pages do today, this could happen automatically
based on the site node (as ad_context_bar does today) and the
intra-package-node. Sometimes which intra-package node you're in
be inferred from the URL, sometimes you'd have to specify it manually
(say if the same page represents different intra-package nodes).
The advantage, of course, is that when you want to redirect to
permissions, and want to let permissions know where you came from,
just have to pass it the site_node and the ID of the intra-package
node where you came from, and the context bar will happen
The even cooler benefit is that this would allow you to build
navigation bars, whether your global one (Company, Products,
Solutions, Training, Support, yadda, yadda, yadda), your out-of-band
one (How to Buy, Download, Search), and your local one (your list of
products in the product section). Each entry points to a site_node
an intra-package node, possibly with some parameter values. It can
automatically do the "show which section you're in" thing, based on
the values that the current site node page sets.
There are a few complications:
First, each node can take parameters (query args), which you want to
preserve in your context bar. For exmample, the bug-tracker index
takes parameters such as the status, component_id, assignee_id, etc.,
from the filter. The site map page takes parameters saying which is
the root node, and which nodes are expanded. Other parameters to the
site map page are irrelevant to keep in the context bar, such as if
you have an edit form active somewhere ... you don't want to keep
if you navigate away from the page.
Second, the (pretty) name of a site node sometimes need to be
parameterized, too. What if you want the name of your bug to appear
the context bar, instead of "One Bug". This could certainly be
by providing some code to set it from the parameters taken by the
node, and caching the result.
Third, some pages, such as the permissions UI stuff, wants to
make-believe that you're really inside, say, inside the bug-tracker
the bboard package, even though in the file system, you're in the
acs-subsite package. Perhaps we need some "symlink" nodes, and what
you do is you tell the permissions page "look, you're really at this
node now, regardless of what you think." Or perhaps
there are better ways of doing this, dunno.
Fourth, we get long and nasty URLs. I don't see any way around this,
since we can't use any other known means of doing this. We can't use
cookies, because we want you to be able to have two windows surfing
the same site. We can't use a URL-based session_id, because we want
you to be able to clone a window and surf different paths from there.
The only thing I can think of to shorten the URLs somewhat is to
encode the site_node/intra-package-node info into one short
ID, and to encode the names of the parameters being passed in some
similar way. We definitely need some kind of encoding here, since
many pages can use the same parameter names.
Finally: What if the sub-package site map itself, i.e., the number
location of nodes, is dynamic? Don't know, but I'm sure we'll run
this at some point, say, in a knowledge library, so we need to think
about this in advance.
Anyway, this was a rather long rant. The bottom line is that I have a
feeling that something like this is in order, but we need to build it
out slowly, and make sure it's flexible/hookable enough that we can
circumvent it when we need to. And we need to come up with something
Any thoughts? Don, I'd love to hear more about what you did for