One of the things I'm discovering is that I don't really know the
best way to implement a portlet. It seems like we're kind of living in
the past with the current implementation strategy. To give a more
concrete example:
There's a portlet that shows web connectors. It has several
possible functions:
- list available web connectors
- display a form to configure a new connector
- display a form to reconfigure an existing connector
- process a new connector form submission
- process an update connector form submission
- confirm a remove connector request
- process a confirmed remove connector submission
- confirm a start or stop connector request
- process a confirmed start or stop connector submission
Right now, we have a single monolithic portlet handler class with
all the controller logic for those. The views are broken down into
separate JSPs, but the controllers are merged and fairly ugly -- it passes
a "mode" around in a request parameter and hidden field, and for each mode
it has to pick out separate properties from the request or server state
and populate those in the "model" that gets passed to the view (currently
by setting request attributes).
Further, we don't handle render requests particularly well. On an
action request, we pass parameters to the render request for that portlet.
But for a render-only request, we revert the portlet to the default view
and settings. In other words, when you interact with any one portlet on a
page, all the other portlets on the page are reverted to their default
state (e.g. the log portlet forgets your search criteria and shows the
default 10 lines of WARN output again, while the web connector portlet
reverts to the main "list existing connectors" screen). It's not clear
how to do this well -- ideally, something would 'cache' the state of the
portlet so it could redraw itself unchanged on subsequent requests, but
the only thing I can think of to do is make all the portlets save their
state in the portlet session, which seems a little unpleasant (as in, the
session might get quite large as there's no hook for a portlet to clear
its state from the session if you leave the page it's on).
I guess I think it would be nice if there were some portletized
web frameworks we can use -- like Struts for Portlets, or whatever.
(FWIW, it seems like several portal servers provide their own struts for
portlet adapters, but I don't see a standard one.) Maybe there are such
frameworks and I'm just not aware of it. It could be great if we could
break up the controllers, provide better render behavior, and standardize
it across all portlets that go into the web console.
Any thoughts?
Thanks,
Aaron
