Forum .LRN Q&A: dotWRK

In the future, I'll use this thread to keep notes about what we're
discovering, what works well, and what areas could use some improvement.

We are planning a projects section for the new site. We are using ETP to manage it, so it would be simple to setup a page to keep track of the progress of the project.

One of the first things I've been doing is going through and changing some of the names of things. Obviously, we don't want our clients to be working in a portal for something called a "class." So anywhere I can, I've been renaming "class" to "project" and "subject" to "client." I'm not quite sure what to do about the "department" level, since we really only need two levels. For now, I'm just calling it "host." I'd want a real dotWRK app should allow for configurable numbers of levels, though.

Anyway, there's good news and bad news regarding renaming in dotLRN. The good news it looks like you can rename things (classes, professors, departments, students, etc.) almost everywhere (although I'm still finding a few holdouts in the breadcrumb trails that I can't figure out how to change). The bad news is that the settings to make these changes seem to be scattered to the four winds. If you go into the (OpenACS) site map, a good number of the nodes under the "dotlrn/" node have parameter settings where you can do name changes. Often names you're changing are the same, too; I must have changed "class" to "project" in half a dozen places. On top of that, there's yet another place you can make essentially the same changes from a class's control panel. It's not really clear which changes affect what, whether there is any cascading, etc.

If somebody in the know could write down a list of all the places you can make these changes and how they relate to each other, I'd be happy to translate that into a HOWTO.

On another topic, I'm looking forward to experimenting with the "copy" feature that lets you clone a class (or project, in our case). We use certain process docs and templates in every project, so I'm thinking we should set up an archtype project portal with those documents already in it and just copy it every time we have a new project. Being able to set up a complete project portal with essentially a couple of clicks will be nice.

At Sloan our expierience was that cookie crumbs did not really result in usefull intuitive navigation for dotLRN. We just use the portal page navigation in the header. We parameterized whether to display cookie crumbs or not so that can go back into OACS core.

Anyway ... the plan for OACS 4.x where "x is not much greater than 5" is to kick context_bars upstairs to subsite master templates where they can be ignored or not as the site designer pleases. Same thing with HEADER LINES. This gives more control than simply turning them on/off (master template can choose just how to display the breadcrumbs etc).

This has been talked about off-and-on in various threads for ... forever. Hopefully we'll get to it Real Soon.

I've looked through some of the adp/tcl for some of the dotLRN components, but still haven't digested adequately to hazard a guess as to where to start.

Looking at News and FAQ tuples ( News, dotlrn-news and news-portlet ) as example of this can be very informative. Also, there are two portlets for each package, xyz-portlet ( user-view) and xyz-admin-portlet ( admin-view as seen from control panel).

We did postgres port for some of those and from that experience, we were quite easily able to write portlet and applet for Wimpy Point and Glossary modules. We are currently testing these modules, and plan to make available code very soon. In general, thanks to great design (contract-based) , it should not take more than one or two days for an experienced OpenACS developer to integrate typical OpenACS package with dotLRN.