On Jun 13, 2007, at 9:08 AM, Joe Bohn wrote:
I've been an advocate of this approach as well so thanks for taking
the initiative on this. I'll take a look at what you've done later
today.
a significant part of this approach is based on the work you did on
little G, as well as the opinions you have been sharing with us about
the need for a more dynamic admin console. so I'm definitely looking
forward to more feedback and participation from you!
There are probably a few issues we'll need to consider if we take
this "plugin" approach - splitting the console components from the
underlying portal infrastructure:
- Uniformity between various portal implementations for how to
define portlet page content, theme/skin definition, and any portal
extensions that we may use.
- Plugin dependencies based upon type - ie. the admin console
plugin would have a pre-req on a "portal" plugin but not
necessarily a particular "portal" plugin if we can pull manage to
pull off this separation.
Perhaps I'm taking this a bit farther than you intended at the
moment. We could certainly just split these components for now and
have the admin console tightly dependent upon a Pluto component.
That does provide some benefits such as in allowing a user to
choose the portal without the admin console and allowing the user
to integrate their own portlets with Geronimo admin functions.
That's a good step forward. Greater flexibility would be in
allowing the user to choose the portal they wish to use but I think
this would require more portal standards that do not yet exist.
I wasn't thinking out that far yet. Like you said more standards
are probably needed before we could think about making the portal
container interchangeable without affecting the portlets that have
already been deployed. I agree that providing a native portal
container that geronimo users can deploy standard JSR 168 portlets
into is a good step forward, and maybe we can make some improvements
to the administration console in the process. Later on the portal or
J2EE community may provide more standardization in this area, so
please help us stay on the right track.
Best wishes,
Paul
