Suppose you want to relate several Sakai sites together. Some use cases:

1. a project site membership has a created a series of subsites to take care of committee work
2. you want to allow users of Fall 2008 course site access to all previous course sites for same course. You can take care of the access issues – but how to make it easier for them to find these other sites?
3. a department needs to provide a set of documents to all courses in it. The sites of these courses need to appear as “children” of the departmental site.
4. etc.

What to do? Pseudo-hierarchy might fit the bill. Run up at an airport by Chuck Severance it establishes a user-interface-only relationship between the sites. This takes place in a breadcrumb that displays below the site navigation paraphernalia.

The full details are here: sakai_pseudo_hierarchy.doc.

The rendering bits are in any version of Sakai after 2.4.x. – to customize for your institution – add the following lines (36-53 in Sakai 2.5.x) from the default.css and then change to suit.

/*site hierarchy breadcrumb*/
#siteHierarchy{
        clear:both;
        float:none;
        margin:0;
        list-style: none;
        padding:.5em 0;
}
/*style the standard breadcrumbseparator
   can set display:none if needed because the
   list-style is taking care of it*/
.breadSeparator{
}
#siteHierarchy li{
        display:inline;
}
#siteHierarchy li a, #siteHierarchy li a:visited{
        color:#09c;
}

You can also add your own separator via the language bundle.

The ability for an institution to configure their local Sakai instance with site types I think underexploited. Or maybe I do not know what people are doing with it. I show how to serve different look and feel for different site types using the same skin. But first – what is a site type?

Let’s say that your institution does not offer courses, but synergymnasiums, no seminars, but collaboratoriums, no discussion sections but hoedowns, etc. These choices can be presented to the user via configuration changes. But it goes beyond the name:  creation of different site types can be associated with different access level people. Maybe only administrators can create synergymnasiums, for example. Each site type also comes with a set of tools to choose from or forced to accept, and after 2.5.x, even with prebaked content into the bargain, etc. There is more to this that am aware of, but for our purposes here, the only thing that matters is that the site type is emitted as a class in the portal markup, allowing us to do different things to a portal depending on the site type. There are 3 spots where this happens:

In the portal masthead:

<div id="siteNavWrapper" class="workspace">
 <div id="mastHead">
  ....
 </div>
</div>

In the site navigation block:

<div class="siteNavWrap workspace">
 <div id="siteNav">
  ...
 </div>
</div>

and in the top most wrapping block of all site content:

<div id="container" class="workspace" >

This means that you can get at, via inheritance, to almost any element in the portal, and do different things to it based on the site type.

At the University of Michigan we have 5 significant site types: workspace, course, project, gradtools, and unspecified. Here is how the first three look like, using the same skin:

The user workspace:

The course site:

The project site:

Since a given user will go from workspace to project (at Michigan any user can create project sites) to course site it was important to make sure they were only subtly different – or different enough to help the user locate herself,  not different to force them to remap things between site types. This was done via color only – the color of the banner text (a background image of one of the children of the .mastHead block), the bottom border of the site navigation, the text of the site title, the text of the current tool, other things. The most radical difference was with the workspace banner text – we found our users needed that extra flag to discern between workspace and worksite.

You can take a look at the portal css of CTools if you would like. All of this is documented as well in the source documentation in the reference.

The remaining site type is the undeterminedSiteType – the default. That is literally the name of the class you need to address, or ignore but provide a css default for to take care of:

Since the default will be triggered when the site type is unspecified, and the only possible cases would be during errors (like Site Unavailable above) or admin type sites – where the stakes are high, the reddish color seemed warranted.

Anyways, this is all short on detail – but the documentation linked to above covers that pretty well.

Sakai has some functionality that may be of interest to solve particular problems but is not well known because:

• it has not been fully tested or
• was addressing very specific needs or
• is not well documented or
• has simply been forgotten

One of these is the Access Servlet. Have you wanted to point your group (define this as you will) to a specific slice of a Resource collection? Without all the Resource management paraphernalia of the Resource Tool? But will all the permissions in full operation? The Access Servlet is there to help.

1 – Choose “Edit Details” of the folder you want to share.

2 – Then click on the “Open” link

3 – The link will open a new window with the contents of the folder – but using the access servlet – looking like this:

All of the “file management” stuff is gone. Also the descriptions are available in the list itself (displayed by default – here toggled closed for the screen shot), which they are not in the OOTB Resources tool. The markup has been been pared down to the bone (an actual list with list items) and the scripting reduced to a nothing. More importantly – all of the access control settings for the whole selected hierarchy are intact – if Folder 2 contents is only available to members of a specific group only members of that specific group will see a link to it. Same obtains for all the other conditional disclosure settings of the folder.

Note and caveat: the functionality is available in Sakai 2.4 onwards, not sure who provided it – but the above screenshots are taken from a trunk build plus 2 patches  available at SAK-13694 and SAK-3804. Please read the comments to both for the caveats and gaps.

An enterprising developer could add an action to a Resource folder to automate this – perhaps adding a tool link targeting the slice to the tool navigation menu. Some institutions, like Oxford seem to be planning to use the access servlet as the main and only public face of the Resources tool it seems, not sure how they are going about that.