IChannel or Portlet

Added by Andrew Petro, last edited by Andrew Petro on Oct 11, 2006  (view change)

In which Andrew discusses when it is appropriate to write and use IChannels and when it is appropriate to write JSR-168 (or JSR-286) portlets.

Draft in progress

This page is a draft in progress that doesn't make much sense yet. Maybe it never will.

Executive Summary

The answer to the question of whether a particular widget should be implemented as an IChannel or as a JSR-168 portlet is the answer to all interesting design questions: "it depends". There are circumstances in which JSR-168 is a far superior solution. There are circumstances in which IChannels are a better solution.

Give up on that IChannel cruft and write JSR-168 portlets

Heads up channel developers, the world has passed you by. Quit writing to an esoteric, uPortal-specific, sadly under-documented API, and embrace standards and frameworks and classloader isolation.

JSR-168 is a standard

Action vs. Render distinction is way cool

Spring PortleMVC makes JSR-168 worthwhile

Control complexity and leverage uPortal by writing an IChannel

Focus on providing real value

Multiple subscribability is a good thing

Multiple publishability is a good thing

Cross-portal? YAGNI

Channel Cache Keys

More .wars means more complexity

JSR-168 is too heavyweight for my problem

More moving parts means more can break

Avoid Both IChannel and JSR-168

If you don't have to run in uPortal's JVM, don't

Loosely coupled is a good thing

Concluding remarks

Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.