Comments on: The Portal is the Platform, Part I

By: Michael Feldstein

Michael Feldstein — Mon, 30 Oct 2006 19:01:25 +0000

I should add that it’s fairly trivial to put an RSS feed or mashup (as an HTML fragment) into a portlet, so most of the Web 2.0 stuff that people have been playing with should move over into a portletized environment roughly as easily as putting it into a plain old web page and play side-by-side with the more sophisticated (and heavy) fully portletized apps.

By: Michael Feldstein

Michael Feldstein — Mon, 30 Oct 2006 18:51:41 +0000

Thanks for calling my attention to this, Scott. The proliferation of FOSS JSR-168 portlets has been somewhat slower than one might hope, for several reasons. First, A number of the portal systems out there had legacy non-standard portlet specifications with many tools already developed to them, so the move over to the standards has been slow. It is comeing, however. For example, uPortal 3.0, due to be released imminently, has native support for JSR-168 and only rudimentary support for its legacy non-standard channels specification. The second problem is that the JSR-168 standard doesn't offer as robust options as some of the non-standard solutions. This is also being worked on, with the second-generation JSR-286 and WSRP 2.0 standards both near finalization. At any rate, in terms of finding JSR-168 portlets today, you can check out the JA-SIG Clearinghouse (registration required), the Jahia portlets repository, the Java.net portlets repository (currently a bit thin on entries), and the JBoss Portlet Swap. There are also some relatively large FOSS and proprietary applications that are compliant, such as the excellent Alfresco content management system (FOSS) and the QuestionMark Perception test engine (proprietary).

By: Scott Leslie

Scott Leslie — Mon, 30 Oct 2006 08:16:11 +0000

Michael, not like you need more work, but I came back to this article recently and to my chagrin found that the majority of URLs you had collected around currently available JSR-168 portlets came back 404. Normally I would just move along and write this off to the aging of the web, except I think this issue, the availability of JSR-168 portlets, is not a trivial one, and in trying to assess the traction of JSR-168-based approaches it would be helpful to know what educational developers can draw on. Any ideas where to find large collections of these? Cheers, Scott

By: Michael Feldstein

Michael Feldstein — Fri, 12 Aug 2005 16:46:28 +0000

Of course you’re right about the My Yahoo! portlets; I meant to use them only as a course-grained example of the portal user experience for people who are not familiar with modern portals. But you make an important distinction.

One of the advantages of having the applications live completely within the portal rather than having people click out to them is that it enforces some consistency in UI. By drawing on standard portal controls, the applications will automatically behave similarly for things like minimizing and maximizing windows, location of the contextual help button, etc.

So, regarding Sakai, I agree that Sakai made a mistake by trying to be a portal, but not for the same reasons that you do. I have no problem with everything being in the portal. My problem is that, if Sakai is going to take the portal-is-the-platform approach, then they should use the already existing and excellent uPortal rather than re-inventing the wheel. Making Sakai into its own JSR-168 consumer doesn’t solve the fundamental design problems of Sakai being (a) too unecessarily heavyweight as a framework, and (b) too narrowly conceived in terms of its permissions, groups, and roles. I would much rather see Sakai broken up into uPortal applications and let uPortal handle the main display, the session management, and the grouping.

By: Ben Brophy

Ben Brophy — Fri, 12 Aug 2005 07:35:05 +0000

In a portal like My Yahoo the portlet is not the application, it is a little feed that leads you into the application. Click a stock quote and you leave My Yahoo and got to Yahoo Finance. Yahoo Mail has a portlet but it’s just a window that tells you how many unread message you have, if you want to send a message, you click a link in the portlet leave My Yahoo and move to Yahoo mail.

So wouldn’t it make sense to develop applications so that they operate independently of the portal, but can send a small preview of their contents over to a portal? Sakai tries to be the portal, and assumes that EVERYTHING happens in that portal, you never leave.

This seems like a mistake, perhaps the best way to integrate UPortal is not to build into Sakai, but export views of Sakai to UPortal via JSR-168. Sakai doesn’t need to be a consumer of JSR-168 (I believe that’s the current plan) rather it can just export little windows into it’s functionality to a larger university portal, that might also include portlets from the school teams, dining services, whatever. That way Sakai tools (quiz and gradebook, say) can share a class website together, and be happily talking to each other, while also each sending a preview to the school portal.