geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bohn <>
Subject Re: Portlet Best Practices [for web console]
Date Sat, 06 Aug 2005 22:53:19 GMT
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<body bgcolor="#ffffff" text="#000000">
Aaron Mulder wrote:
  <pre wrap="">On Sat, 6 Aug 2005, Jeremy Boynes wrote:
  <blockquote type="cite">
    <pre wrap="">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).
  <pre wrap=""><!---->
	Is there an official struts/portlet integration package?  I didn't 
see one.  Can you point me to it?

I don't think that there is a standard struts/portlet package (at least
I'm not aware of one).&nbsp; JetSpeed has<br>
it listed in their roadmap but I don't know if that is something going
into the next release or not.&nbsp; I would<br>
much rather find an implementation that we can include instead of
creating from scratch.<br>
  <pre wrap=""></pre>
  <blockquote type="cite">
    <pre wrap="">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.
  <pre wrap=""><!---->
	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.


If we think that the console itself is going to be fairly large then
perhaps we should consider pulling<br>
in JetSpeed.&nbsp;&nbsp; So far it seems as if the cost of doing that is out of
line with the benefits gained .. but<br>
if we are thinking about opening up the portlet container for others to
use in the near future then <br>
it would make sense to get more involved with JetSpeed.<br>
<pre class="moz-signature" cols="60">-- 
Joe Bohn     

<a class="moz-txt-link-abbreviated" href=""></a>

"He is no fool who gives what he cannot keep, to gain what he cannot lose."   -- Jim Elliot

View raw message