Forum OpenACS Development: Different views of a package at different locations in the site map

I am developing a package that UI/requirements-wise naturally wants to be mounted at different places in the sitemap.

The package might be thought of in terms of a hypothetical blog package.

Users of the site would be casual visitors, and blog owners. It might be broken down further (owners vs. authors vs. publishers) but it doesn't need to be for my question.

It would seem to be natural to make views of the application available at:

/jade/blog -- jade's blog
/lars/blog -- lar's blog
/daveb/blog -- daveb's blog

/blogs  -- a list of all blogs on the system jade's, lar's, and daveb's.
If I visit /jade and then /jade/blog, I would want a navigation/cookie crumble path that suggests:
/jade | /jade/blog
If I visit /blogs and then jade's blog, I would want a navigation/cookie crumble path that suggests:
/blogs | /blogs/jade   OR
/blogs | /jade/blog
So what is the best (practice) recommendation for developing this on OpenACS 4? Are there two packages (blog and blogs) here? Is this one package just mounted in different manners, perhaps with package parameters that change the behavior?

What is the best way for the code to build and maintain the navigation/cookie crumble path?

Surely the best practice isn't to confuse the user with alternate paths leading to the same place, but to say that Jade's blog is at "Jade -> Jade' Blog" and within the blog's content, state that the Blog is of type "Blog" and that the visitor can see other Blogs at "Blog".  Anyone?
I should have referred to this as a breadcrumb trail.

Imagine a site,, providing room reservations services to everyone in the hotel business.  They have two streams of income, first from the business from each hotel chain, and second from their own priceline/expedia like service.

If you visit a participating hotel chain, that hotel chain will want a certain amount of branding, and will not want competing hotel chains' inventories shown:

/hilton | /hilton/sanfran/ | /hilton/sanfran/unionsquare

if you visit them first at, they will want to to show you any hotel rooms that match your requirements.

/sfbayarea | /sfbayarea/sf | /sfbayarea/sf/hyattunionsquare
/sfbayarea | /sfbayarea/sf | /sfbayarea/sf/hiltonunionsquare

Perhaps you browsed their inventory in a cost sensitive manner, maybe they want to show you the breadcrumbs indicating the search path you chose, a mixture of geographical and monetary constraints, and not just the geographical location bundling:

/sfbayarea | /sfbayarea/$$ | /sfbayarea/berkeley/pinkflamingo

Does that make more sense?  How best to fit such an application in with the site map, and how best to generate the breadcrumbs?

I'm kind of spinning my wheels with the breadcrumb as well. One thing I hate is that it is essentially built from the context variable, and you have to make sure every page passes this up.

How much context should a page maintain on its own? How does a page appear in more than one context? Once you make a change to a page title, do you then need to go around and change all the sub-page context variables?

The context is really a little database of information that is inflexable and hard to maintain. I tried moving navigation into a separate data model and it partially works for top down navigation, but what I wanted it to do is to allow what I was calling 'virtual' navigation. A single page should be able to have multiple contexts, and the breadcrumb up should change depending on the context. Also on the way down from the top, you should be able to find a page (which is just a set of functions with inputs) to display what you want.

Another issue is website browse order. This is similar to the paginator app which breaks down the listing of data from a query, but applies to web pages. Some sites will have a chapter like structure, each page being part of a chapter or topic. Once you finish one chapter you need to move on to the next. Something like the tree_sortkey idea might work for this, imposing a site wide order on browsing.

Another issue with navigation is url hacking and 404 responses to missing or moved pages. A centralized navigation system would recognize what the user was looking for and help out with navigation aids. At the same time search bots should be alerted that the information really isn't there anymore by seeing a 404 response.

Jerry, check out my feeble attempt to work with some of these ideas.

These were some of the same thoughts I struggled with a little over a year ago here:

I'm thinking that a package should define its page or node structure in a Tcl library file somehow, including node that others can link to.

The intent is that you can setup a link between, say, a page in forums and the permissions page from acs-subsite, and say tell permissions the ID (package_key.short_name) of the node that you're coming from.

The tricky part is that you're not *just* coming from a page, you're coming from a page which has query vars, such as forum_id included in it.

So basically we have a stack of parameterized nodes to maintain, which will be tricky to squeeze into the URL nicely.


Jerry and Tom,

The content repository can solve this, although there might be a performance issue with getting the paths.

Using cr_folders, you can place a content_item in a folder using parent_id.

You can place and item in more than one folder using cr_symlinks.

You can also define ordering to items using cr_item_rels, giving items and ordering based on their relationship to another item. So for something like chapeters, you'd create a "booK" item and relate each chapter with cr_item_rels setting the order in the cr_item_rels table.

Lars, I responded to your message from a year ago over there.  I agree these are related issues.  I think I favor the context as push-down-list -- I believe that handles a lot of the requirements I have seen.

Tom, I think your issue of 404s and imposing a web site structure is related to this issue that I also am having:

If you have an application that is made of one or more packages mounted at two or more (many!) different locations, how does the application determine the other locations?

Going back to the /blogs example, if jade comes and visits

/blogs, then /blogs/jade, then jade should see an admin link to /jade/blog/admin and similarly, when dave visits /blogs/dave he should see a link to /dave/blog/admin.  Unless when these packages were mounted, the site admin mounted jades at /jade/blog and dave's at /tdx/daveb/blog

When mounting the same package at different locations, when a package can be mounted at arbitrary positions, how does any package determine the url of the correct instance of another package?

As of (quite a while ago) I hadn't seen a good way to do this, there was still a lot of hardcoding going on, or assumptions being made.  What's the scoop now?

If there isn't a solution for this yet, I would like to see some sort of publish-cabilities, published-service registry created.  Each package instance would have the ability to create a registry entry saying, I provide this service (blog), identified with these parameters (user = jade), and my canonical url is this (jade/blog).  Does anything like that exist?

We could optionally enhance that with (I provide these services at these urls, examples: blog is at jade/blog, admin is at jade/blog/admin, trackback is at jade/blog/trackback)

I think that would help out some of the 404 problems.  It would make it easier to keep 404s from occurring (does this service exist?  where is it?  does it provide this service?  where?)  And it would let the 404 handler provide a catalog of other or alternative services.