How is using portlets any better than just using server side includes?

Question

The idea behind portlets is that a website/page can be comprised of a number of applications that are developed individually. They are then fit together on a page by a portal much like a jig-saw puzzle. This allows functionality to be created independently and slotted together at a later date. This has many obvious benefits.

However. I cannot see how the portlet specification improves upon older ideas like server-side includes, from the point of view of a developer who needs to get something done, as opposed to publish a paper or make a keynote address.

The tone might be a bit negative, but my first foray into the world of portlets has left me thoroughly disenchanted.

Answer 1

From the point of view of the job of just 'including' some dynamic/static content on a web page, you're correct.

However there are a number of conveniences implemented, such as support for personalisation of the portlet (at the portlet/'include' level) and storing this info, a more rigid workflow for configuring what is displayed in the portlet and so on.

Plus obviously there's all the portlet arrangement code that you would have to write otherwise. Some portlet servers do a lot on the client side for arrangement (drag and drop of portlets etc).

You may find some of the discussion at the below URL helpful: http://www.ibm.com/developerworks/ibm/library/i-portletintro/

Answer 2

For sure, the portals create the view essentially by doing lots of server side includes. The portlet specs (JSR-168, 286) just define how to code a portlet so it fits into a portal. They only define things necesary for portlets to co-exist on the same portal page, things that are not a part of J2EE servlet or JSP definitions.

Without the specs, it would be hardly possible to use portlets from different development teams, or even different vendors on a single portal page.

Even a single J2EE application with a portal-styled UI can benefit from use of a portlet container - it can help to accomplish many typical UI-related tasks.

Consider e.g. these features defined by portal specs (just a very few):

• Portlet lifecycle, isolated from other portlets.
• Isolated URL spaces for each portlet
• Portlet modes and window states
• Portlet session scropes
• Personalization, portlet preferences. Users configure apperance of their's portal pages by positioning and setting individual portlets.
• Raising / comsuming of events (JSR-286)
• ...

The specs are not a rocket science, and also they do not pose a paradigm in UI design or so - to me, the most revolutionary about portals was the idea of a user's desktop brought into web applications.