Regarding #1 below ... I think there are probably some good reasons to
keep this split into 2 or maybe even more web applications.
As you mention, the "framework" appears to hold the necessary components
for the console framework itself. Since this may be replaced
at some point in the future by an open source Portal Server (not just
the container) it probably makes sense to keep this split apart.
The "standard" application includes the portlets necessary for console
administration. One of the benefits of the portlet model (and I
suspect the reason it was chosen for the console) is that it is
extensible. Multiple applications can be installed as necessary. This
seems
like it would be a desirable feature for a modular server like
Geronimo. If there is no need for the EJB container it need not be
included in the resultant image and therefore the portlets that
administer the EJB container would not be deployed into the solution.
I wasn't one of the authors of this console structure but I can see how
it makes sense in the big picture even it is seems like overkill for now.
For #2 I think that it is a good idea to provide some level of
abstraction between the view (console) and the model/controller
(kernel). However,
is it really necessary to integrate these changes into the initial
donation? This is all internal functionality to the console and the
kernel functions
are not exposed via any other mechanism beyond this. Can't we discuss
what this abstraction should be and then move the console over to
this public interface when it has been created? I'm not sure why we
would want to hold up the initial contribution of the console for these
internal changes / new interfaces.
Aaron Mulder wrote:
So I took a look at the web console. There are two main changes I'd like
to make before we "go live" with it.
1) Combine the "framework" and "standard" web apps into one. Currently
the "framework" holds the Pluto engine and page framing and so on,
while the "standard" holds all the actual portlets. Some of the issues
are that I don't really fancy taking two contexts for this, there's no
security on the portlet (standard) context, it can be accessed directly
with a variety of unpleasant side effects, it makes the whole thing
require multiple build modules and an EAR, etc.
2) Separate the "data access" from the "UI". Right now the portlet code
is making kernel calls to load the data it presents and alter the
GBeans when changes are submitted. Besides the obvious issues with
this architecture for the console app itself, this means the
configuration layer is not reusable by other tools (for example, a
command-line tool to change network ports or whatever). There's also
some supporting GBean code for the console that could hopefully be
rolled into this layer.
Personally, I'd like to start with the second item. I'm hoping someone
else can take a look at the first one. I guess my thought on how to
proceed with that one would be to clean up the layout of the "framework"
WAR a bit (put most of the files under /framework or something), put in a
couple placeholder portlets just to prove that Pluto can display portlets
from its own web app, and make this the basis of a new "web console WAR"
module in Geronimo apps.
Then we can start updating the donated portlets to use the new
configuration API (#2) and migrate them into the new console WAR (#1). I
also have some thoughts on changing the layout/ordering of portlets, but
that's not such a big concern right at the moment.
Finally, there are a lot more portlets and features I'd ultimately like to
add to the web console, but that's definitely a discussion for another
day. :)
Thanks,
Aaron
--
Joe Bohn
[EMAIL PROTECTED]
"He is no fool who gives what he cannot keep, to gain what he cannot lose." -- Jim Elliot
