This is a draft of my self-assessment of my activities for the past fiscal year as part of the UM evaluation process. Thankfully there is no numberic scale that I was forced to rate myself on.
It is only a draft and may be revised in discussions with my supervisor – comments welcome..

Continue reading →

The 2.4 release has basic support for PDAs – see /portal/pda in your server – the PDA portal has its own style sheet:
/portal/styles/portalstyles.css
The 2.4 release also has the workgroup portal support as well:
https://source.sakaiproject.org/svn//reference/trunk/docs/architecture/sakai_workgroup_portal.doc
Sakai 2.4 also has support for RSS, Atom, and OPML:
/portal/rss /portal/atom /portal/opml
These show sites, announcements, etc – give them a try.
After 2.4 was release a bunch of features were added to trunk in /portal
Making the PDA portal optionally eliminate iframes – experimental feature
Hierarchical site navigation
I include some properties to play with.

Continue reading →

I have to run off and do family things the rest of today – but I just updated the portlet – and it works swell now in uPortal 2.5 – previously it did not work so well – missing commons-collections.jar.
A cool new feature is that parameters in the portlet.xml can be overridden by adding preferences in the uPortal admin interface – so you should *NEVER* have to touch the portlet.xml file.
Another cool feature is the mighty-morphing web.xml which works in either Pluto 1.0 or Pluto 1.1 without needing a patch – just drop into Sakai’s or uPortal’s webapps directory and let it fly!
Two important parameters to set in uPortal’s channel setup are:
sakai.host = http://localhost:8083
sakai.secret = plugh-xyzzy
And another fun one is
sakai.allowpref = true/false
If this is set to false – the user cannot set prefs via Edit-mode. Of course in uP2 you can disable the Edit button – but for portals that show the edit button – this pref stops pref changes from happening even if users find their way into edit mode…
If you want to hack look and feel – open up the war and edit “feed.vm” – a Velocity template for the output production.
Documentation is coming.

I made the following web.xml in my war – and it works directly in Pluto 1.1 and Pluto 1.0 environments – at least it works in Sakai 2.4 (Pluto 1.1) and uPortal 2.5 (Pluto 1.0).
I initialize the servlet with both sets of parameters (thankfully no overlap in names) and then provide two servlet mappings.
It seems deceptively simple. Of course this is doing wildly different things at run-time – but depending on whichever Pluto you are running – it sees what it wants to see and ignores the rest.
Comments/feedback please.

Continue reading →

I just finished writing a simple Sakai Dashboard JSR-168 portlet. The portlet logs into a Sakai server on behalf of a user and retrieves and RSS feed of the sites and their announcements for the user. Then the feed is displayed in the portlet – all of the links are target=_new so there are ZERO iframes in the portlet and portal.
I need to write documentation for it (of course) – but the code is here:
https://source.sakaiproject.org/contrib/portlets/trunk/
This directory now can be checked out and compiles *outside* of a Sakai source tree – it only needs the Sakai maven plugin.
maven plugin:download -DgroupId=sakaiproject -DartifactId=sakai -Dversion=2.2
This portlet configures and operates much like the Launch Portlet that we have had for a while now. It uses SakaiPortalLogin.jws like the other portlets. The Dashboard portlet can be configured via Admin-specified preferences in addition to the portlet.xml -this should make it easier to install and configure.
I use Rome to retrieve and parse the feed – all the markup is in Velocity. I have code in place to retrieve the raw feed in case someone wants to apply some XSLT to it to make it prettier.
Yes, I know the portlet is ugly – that is why all the markup is in Velocity so folks can fix it for me – or just switch to XSLT. I am going to run through some deployment scenarios in uPortal and Pluto and write some basic documentation about how to set things up.
I took the opportunity to go through the portlets and do some general cleanup and improve some patterns as I have gained more experience in writing portlets and portlet support code.
Thanks to Alves Phillipe from Pierre-Marie Curie Institute who worked with me at JA-Sig on the idea to get me started.
Comments, patches, etc needed and welcomed. I use a new mechanism to retrieve remote user, etc – so I need a parch to my lookupPortalType method in PortletHelper.java for Gridsphere and Oracle.