I was recently asked about how hard it would be to port the Sakai Basic LTI portlet to Liferay. Here is my Sakai JSR-168 portlet for Basic LTI:
https://source.sakaiproject.org/contrib//ims/basiclti/trunk/
I don’t have any experience with Liferay. I did not write the portlet with the intention of running outside of Sakai. I did try to limit the number of files where I used Sakai APIs – but since I wanted this to be a well-integrated Sakai tool that followed Sakai patterns – I needed to use Sakai APIs where appropriate.
Here are some files to look at with Sakai specific code:
basiclti-util/src/java/org/sakaiproject/basiclti/SakaiBLTIUtil.java
basiclti-util/src/java/org/sakaiproject/linktool/LinkToolUtil.java
These files localize the calls to Sakai APIs to get information like user name, course name, etc. You need to write a Liferay version of this file. Ignore the LinkTool stuff – is adds Sakai extensions to the launch – there is no need for these in Liferay.
impl/src/java/org/sakaiproject/basiclti/impl/BasicLTISecurityServiceImpl.java
This is very Sakai-specific code that gives us a servlet like view – fully provisioned with Sakai’s session, security, course, and user identity – this is probably a complete rewrite. Look in the IMSBLTIPortlet.java code and search for “access” this is where we are calling this servlet – I would guess Liferay has a similar Portlet to Servlet connection. You may be able to do this in JSP by simply sharing session between your Portlet and Servlet. In Sakai it is trickier because we don’t provision JSPs with all the session information. And even if I could do this through a servlet session in Sakai, I would still want to call the Sakai security APIs to avoid security-by-obscurity holes and avoid timing problems of multiple launches from the same session.
portlet/src/java/org/sakaiproject/portlets/IMSBLTIPortlet.java
This is the core user interface Portlet. This is actually pretty portable – but it does have some code to look up Sakai properties to let system admins mess with LTI tools from their interfaces and lets System Admins build “pre-configured” tools. Most of that can be simply removed to make a basic working portlet. Also this code calls Sakai APIs to set the tool title and the button text for the tool to be displayed in the portal – these features can be removed or done differently.
portlet/src/webapp/edit.jsp
portlet/src/webapp/editreset.jsp
These only use Sakai for internationalization.
portlet-util/src/java/org/sakaiproject/portlet/util/PortletHelper.java
This is actually an attempt on my part to genralize and make portable subtle differences between JSR-168 containers for things like user name, E-Mail, etc. You can either add Liferay code to it (I would be happy to take patches) – or just remove the Sakai/uPortal/GridSphere code and replace it with Liferay versions of the methods.
In general, porting will be a bit of work – sorry – my intention was to make this a very nice tool for Sakai and so while I tried to limit my use of Sakai APIs to as few files as possible (6 files out of 42) – I wanted this tool to be a very much Sakai tool and fit in nicely with admin-friendly features.
You might find it easier to just start with my completely portable Java/JSP code and derive a simple Liferay portlet from that. You will note that many of the files in this code are identical to the files in the Sakai portlet – I use my IMS reference implementation code in the Sakai portlet. So if you use this code – we can stay together with the bits that actually do the Basic LTI calls.
http://ims-dev.googlecode.com/svn/basiclti/trunk/java-servlet/
You could certainly look at the configuration UI I use in my tool and borrow as much as you like (yay for open source and open ideas!). Note that the “Display Properties” is Sakai-specific and affects the look of the Portal’s Button and title.
Let me know how it goes.