Dave's Blog

(Apologies to non Sakai readers - this post is about programing not canoeing!)

In my last post I talked about the planned re factoring of the polls tool in preparation for exploring a K2 version of the service and tool. This is now largely complete in trunk. The only thing left is increasing the unit test coverage. The work done includes:

1. Making use of genericdao for data access
2. Moving all dependencies on Sakai services to an external logic class
3. Writing unit tests to cover the core functionality.

This had the effect of removing repeated code, ensuring that the logic layer enforces business rules about objects, rather than delegating it to the dao layer. In this sence it was a useful exersise even if we we'ren't going to look at K2.

Where to from here?
With the version of the tool as it stands we should in theory be able to make a stand alone version by:

1. Packaging everything in a war
2. Stubbing external logic
3. Setting up hibernate to access a database on its own (not use the Sakai session factory)
4. reconfigure the RSF setup to remove the Sakai dependencies.

This may be a good way to approach the migration - I'll have to look in more detail at how the Sling based kernel works.

Concepts to figure out
The move of the Sakai dependencies to the Externals class has also given a useful checklist of concepts that we will need to explore in K2, they are:

1. Data access
2. Permission
3. User information -
   1. current user
   2. preferences
4. sites a member of
5. Information about the site
6. Placement - where is the tool placed

Some of these (e.g. placement) will probably need a re-examination due to different idioms in K2 .