Mark Nortons one-and-a-half hour Framework walkthrough

By our guest author Gissur Jonsson
Mark Norton has made som forays into the nature of the framework in Sakai 2.2 and has emerged with quite som information. In general, refer to his slides for API specifics. My interests was mostly in his understanding of the AuthzGroup and the GroupProvider but there was alot about the new Entity model.

Entities provides a common model for working on objects within Sakai that has persistence and maybe uses outside of their originating tool. A good example is the resources but also syllabus entries and stuff like that springs to mind. Entities has a reference to the Producer who made them and they have Properties to describe their metadata. Edit extends Entity and provides mutability to the Entity object. The Entity Bus or the Entity Model will be a focus for futher development as a central service in Sakai. I expect a lot of kernel or core usages to spring from this model.

The actual blog from the session is quite extensive and probably not very interesting for the non-initiated non-coding person. So I'll try to wrap it up in a few words and then attach the rest of it as notes under the wiki presentation entry.

The overline of the five (formerly known as six - but Security and AuthzGroup got collapsed into one) models is as follows:

• User Model for user properties and authentication (used to be in kernel). A UserDirectory provides searching capabilities for User objects with UserEdit objects as a way of changing information about users. External providers are implemented through UserDirectoryProvider and returns filled-out UserEdits for the queried user. A new thing is the external eid as a separate id to Sakais internal (cryptic) id. In most circumstances you would want to show users their eid...


• Tool Model - I kinda missed the essentials here, not even sure if this is the proper name for it. But it breaks down to separating tools into a tool part, a service api part and a service impl part. At the lowest level, it should hook into the framework. All the other parts should only depend on own APIs.


• Security Model manages permissions for users by a unlock-by-key scheme. It's basically just a function (lock) that is granted (by key) to a user, managed by collecting users in groups called authzgroups (formerly realms). Likewise a set of functions are collected in a role that expresses a given set of users' rights within a site context.


• Content Model manages all uploaded documents etc. It can be stored internally in the database or (recommended) externally on the file system. A limitation in the content hosting model means that all backup and restore is per server instance, not user instance.


• Site Model wraps up all kind of site-specific things, like tool placement etc. Of particular interest was the notion that pages is not the same as tools. You can have more than one tool on a page, but in other circumstances only one tool per site is allowed. Try for instance to use admin site editing to add more than one chat tool pages to a site - it will actually be the same active chat for both pages.

And that's it - sorry about the noisy first edition - if you are interested in the full edition, go to this site.

You can find the slides here at a later date