By jtb on May 07, 2008
What's the hard sell when it comes to portal technology? Divide potential portal users up into two groups:
- those that are either starting from scratch or willing to burn what they have and start over
- those that aren't
Most people fall into category 2. They have a website that's a hodge-podge of technology. It may be portal-like, but doesn't use any portal software to render pages. They don't have the resources or the stamina required to start all over. And there's the problem. Portals require you to use their proprietary page-building technology. Each portal does it differently. There's the portlet standard, but that doesn't handle the overall page, just the content inside the "boxes".
What's really required is the ability to evolve an existing website to use portlets. How about a portal that can syndicate portlet content, allowing the content to be pulled into existing websites?
We did a proof of concept of this for the WebSynergy project at JavaONE. Click on the portlet's icon (upper left corner) and get a popup giving the portlet's URL. In the simplest case, this URL can be used as the source for an iframe. To see it work, just paste it into your browser's location bar.
This idea has obvious problems ...
- iframes: generally disliked because of possible security issues around pulling content from 3rd party websites.
- authentication: how does one share authentication / identity between the website and the portal?
- styling: does the portlet rely on styles provided by the portal? How can the styling get pulled with the content?
Solving the iframe issue requires some changes to the portal core. Specifically, clicks on the portlet need to be routed back to the portal server, and the browser needs to return to the website page after processing. The default setup on the portal will return the user to the portal's page after processing (hint: getPortletURL()).
Authentication might be handled by something like OAuth.
Styling could be handled by encapsulating it within the portlet. It could also be handled by providing an extra layer around the portlet URL that injects style into the resulting page. The website tells the portal that it wants portlet X with the Y style.
Just some ideas.