Portlet Best Practices [for web console]

[Aaron Mulder <am...@alumni.princeton.edu>]

	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

Re: Portlet Best Practices [for web console]

[Aaron Mulder <am...@alumni.princeton.edu>]

On Sat, 6 Aug 2005, Jeremy Boynes wrote:
> On the framework side, there are a couple but the separation between 
> action and render gives problems for some e.g. the Struts portlet 
> framework originally double dispatched to the actions (not sure if that 
> has been fixed yet).

	Is there an official struts/portlet integration package?  I didn't 
see one.  Can you point me to it?

> The other thing that seems ironic is that most of the portlets are 
> probably going to be very small implementations and there is a good 
> chance that the footprint of the framework will be far larger than that 
> of the portlet itself.

	Well, I'm not so sure that's true.  I listed like 9 functions of
the web server manager portlet, and the EJB server manager one will be
nearly identical.  I think the database, JMS, and application portlets are
going to be similarly complex (list, deploy, configure,
start/stop/undeploy, confirm action, view DDs, ...).  CORBA and security
realms seem likely to be fairly ugly too.  Overall, I think cleaning up
and standardizing the complex ones like that is worth almost any amount of
overhead on the super-simple ones like the JVM system properties view.

Aaron

Re: Portlet Best Practices [for web console]

[Jeremy Boynes <je...@boynes.com>]

Aaron Mulder wrote:

<snip/>

> 
> 	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.)  

<snip/>

> 
> 	Any thoughts?

On the framework side, there are a couple but the separation between 
action and render gives problems for some e.g. the Struts portlet 
framework originally double dispatched to the actions (not sure if that 
has been fixed yet).

The other thing that seems ironic is that most of the portlets are 
probably going to be very small implementations and there is a good 
chance that the footprint of the framework will be far larger than that 
of the portlet itself.

--
Jeremy