The Problem with Portlets

Thursday, October 01, 2009
Great quote from this article on JPMorgan's use of Flex:

It has the look and feel of a portal with several portlets, but Cassar stresses that it is in fact so much more. "It's a set of very tightly integrated applications in a container," he says. "The problem with the portal technology is that usually the interaction between the portlets isn't there-they each kind of stand alone. They have to run in their own browser sandbox, whereas this really allows for the more tightly coupled interaction."

Ain't that the truth. There are some architects that go around telling people that their applications, in fact all applications, should be portlets or mashups or gadgets or whatever term we're using now. This started in the Java world and seems to be gaining traction in the AJAX world as well. Count me out.

Eclipse and Potomac applications are better examples. They're made up discrete components that can truely integrate together.

I'm currently working on enabling untrusted, cross-domain bundles in Potomac. My primary goal is to ensure that untrusted bundles can integrate deeply with the main application. We have to move away from iframe-like integration - what I like to call integration via rectangle. Flash's security model is essentially the same iframe-like model. In Potomac, we hope to enable better/deeper integration, while still being secure and easy to code.

p.s. I wonder if those JPMorgan guys have looked at Potomac? ;)


  • Alan Plante

    I am by no means an expert in the various widget-specs or offerings, but I couldn't agree more. I've faced this recently in my organization where we were supposed to create an entire UI using iWidgets. The only interaction between widgets is through events. In and of itself this is not a problem, since widget specific events, custom events if you will, are perfectly valid constructs. The problem, in my opinion, is with the containers themselves - they don't provide a rich enough set of hooks (events, callbacks, etc) to build anything more than disconnected dashboard-y type applications. Contrast that to the Eclipse model where there is a rich set of "container" services (selection, lifecycle - save/close/etc) that editors and views can leverage in order to build truly rich applications. In my mind, views aren't really much different than dashboard widgets. Editors though allow you to build applications with focus on a specific entity (I hesitate to call this a document). So you have the best of both worlds - if you want a dashboard-like application then use views; if you want something more traditional then provide some editors with views decorating the editor.

    I'll be interested on where you take Potomac in this regard, since now that you have an extendable, modular platform in place I can see how you could also leverage some of the core Eclipse concepts to allow rich, cohesive applications to be quickly developed.

  • Post a Comment