Sakai Conditional Release Developer's Guide

Motivation

Design

The first design attempt produced a plan for a system that would encapsulate into a Rule arbitrarily many queries to arbitrarily many Sakai services. In this way, if a particular resource were protected by a Rule, accessing the resource could cause a request to the GradebookService, another request to ContentHostingService, and so on. This design was deemed too chatty for reasonable performance in the Resources tool, which must conform to many of the performance characteristics of a file system.

...

Sakai has a built-in mechanism for responding to events, called the NotificationService. Clients of the service ask it to create objects of type Notification. The Notification extends Sakai Entity and specifies three additional key pieces of information: Excerpt

hidden	true

1. one or more strings containing event types to respond to. These are called functions.
2. a string called a resource filter which indicates which resource may be affected by the event.
3. an object of type NotificationAction which has the notify() method for taking action in response to the event.

...

hidden	true

The conditions module contains an implementation of NotificationAction called ResourceReleaseRule, which also implements Predicate from Apache commons-collections. The purpose of Predicate is to add a boolean evaluate(Object arg) method which answers the question "Has the condition been met?" The notify() method checks the condition and then takes the necessary action to update the state of the ContentHostingService.

...

Sakai's BaseNotificationService has its limitations, notably that it requires any implementations of NotificationAction to be physically inside its component WEB-INF directory. Also, it uses manual manipulation of DOM objects for persistence, which is error-prone and yields object storage in the database as a lump of XML.

TO-DO

Here are a few less glamorous things that need doing. These are some suggestions that any volunteer developer could tackle.

• event pack should not have to declare a dependency on conditions-impl. This is in there now in order to avoid a ClassdefNotFound error when we ask the NotificationService to reconstitute a ResourceReleaseRule from the database. It should be able to get a Class object from the Sakai ComponentManager instead. Look in BaseNotificationService for where it does this:

  Code Block
  m_action = (NotificationAction) Class.forName(className).newInstance();

• GradebookExternalAssessmentServiceImpl should not use a static cover of the EventTrackingService. This is a case of doing the quick thing rather than the right thing. There's a Spring bean configuration file in there. We just need to modify it to add an injected EventTrackingService.
• The behavior of the content tool UI should not depend on the index number of items in the <select> tags. There are hard-coded references to magic indexes in ResourcesAction, ListItem, and sakai_properties_scripts.vm. It's ugly.
• Speaking of ugly, the UI does not degrade gracefully if any parts of the form become very long. The box for adding a point value becomes orphaned on the next line. Someone with HTML chops could make it nice.