…when you have the Sakai Entity Broker and jQuery in your hand. It is an extremely useful combination that certainly has a place in Sakai 2.x.
At some point, for example, one of us snuck in the FCKEditor for editing a Sakai site description. The problem is, the display locales for the site description were not designed to render gracefully complex/long/enormous/gigantic blocks of stuff, they were reserving space for the original plain text description only !
One solution is to strip the html and display the first “n” characters (KNL-133). This solves the problem of the rich text description mangling the context (gateway sites list, site info, etc.).
And yet the original information in the site description was of importance to the person who crafted it – how to make it available again? Enter the Entity Broker. Since the context provides the ID of the site the RESTful url to the site’s information is:
‘/direct/site/’ + siteId + ‘.json’;
The rest is a matter of parsing the site JSON, extracting the useful info, and displaying it in (following Noah Botimer’s recommendation) a jQuery UI Dialog. The details can be found at SAK-15861 – the trickiest part was manipulating the dialog to display correctly in an iframed environment, but luckily the jQuery UI Dialog was very tweakable:
We considered other places where this would be useful. One obvious place was in group selection instances. When creating an assignment, targeting an announcement, restricting a resource access, etc., you can select what groups are involved. A modal dialog displaying the group’s membership might be good (“Who is in this ‘The Scroungers’ group after all?”). As with the site description there is a handy url:
‘/direct/membership/group/’ + groupId + ‘.json’;
That can be parsed for useful data which can be displayed in a dialog, this time with the addition of a print preview link that might be helpful.
The combination of the Entity Broker and jQuery makes this absurdly easy, there is no actual, um, development in the traditional sense going on here. A project we are almost done with at Michigan uses an “entitized” provider to display to a user a list of the courses they are enrolled in, links to the corresponding site if any, as well as a way to navigate to past and future terms. This was designed to address the “Where is my course site?” issue that the tab metaphor unfortunately produces as a side effect.
Once the heavy lifting was done entitizing the provider (thanks to Savitha!) the view component was not only fast but fun to produce. We used a velocity template but only to load the language strings into a json, otherwise it could have been just some html.
The urls in this case were, to retrieve the terms that the user was registered for courses:
“/direct/mycourses/terms.json”
This is used to build the navigation menu for the user. The current term and any the user picks is retrieved via:
‘/direct/mycourses/’ + termId + ‘.json’;
The json gets parsed and the UI gets constructed (blurred here because this is an actual person/persons, real CM data):
That is it. This is happening in these msub branches: CT-912 mycourses and CT-912 ctools-provider.
There are a few things that need a lot of work. For one, since this is mostly DOM manipulation (all of the information of value here is the result of DOM manipulation) and since it is sort of a central piece of information (what are your courses, where are the sites) it makes it both important and difficult to ensure it is accessible. Will be studying ARIA ways of addressing this.
Gonzalo Silverio's Weblog 