Elliot Metsger wrote:
General,
A thread has been started on pluto-dev [0] about adding some
functionality to the Pluto container which debatedly is "portal-like".
1) Encapsulating portlet assembly in the container, instead of pushing
that down to the portal and the portlet developer.
2) Implementing hot deployment in the container itself, allowing
portals embedding pluto 1.2 to leverage a common implementation of
deployment.
Both features would have callback interfaces delegating portal
specific functionality to the portal.
We'd like your reaction to the idea before moving forward.
[0]
http://www.nabble.com/hot-deploy---auto-assembly-design-tf4041191.html
First, I'm not sure what the problem is. I thought that pluto's
container was a "sample" to prove that the pluto spec implementation
worked. If so, what's the problem?
Secondly, a thread popped up here a while back regarding doing Ajax
support outside the JSR spec, since it apparently was purposely left
out. At the time I found myself wondering if that was going to be
incorporated into Pluto or somewhere else.
Also, I've been working with portals for a while and have been running
into all kinds of problems that are outside both JSR 168 and 286. I've
debated starting a thread like this one so I suppose this is a fine time
to bring them up.
I have several related portlets that need access to the same or
variations of the same data. Now, while the spec provides for action
requests and render requests, the first time a portlet is called it has
to retrieve its data in the render request. Now if these portlets reside
on the same page then currently the spec pretty much requires that the
data be retrieved via business calls during the first render request
(I've never understood why it was defined this way since render should
mean "render the data your already have). A much better solution would
be for the spec to allow a way for portlets to be called the first time
a page is rendered, possibly as a two pass process to allow all the data
that is required to be identified and then a second pass to get it.
This would dramatically improve performance and also clean up a lot of
the render logic.
Second, a whole bunch of stuff related to login and user attributes is
missing. In a typical portal when the user logs in a lot of items are
retrieved in the way of user preferences. There is currently no good way
to do this - i.e portlets should be able to be called during login to
either retrieve data or be passed it.
In other words, the whole idea of having "portlet applications" is
completely missing from the spec.
I've raised these issues on the JSR 286 list and the feedback I got was
not that they weren't real problems but that getting the spec out was
more important than solving them.
I've currently gotten around all these problems by using proprietary
extensions to the portal we are using. Obviously, this is a less than
ideal situation.
So the real question is, are we here to just implement the RI for the
spec or can we go beyond it and if so, how?
I realize I didn't really answer the original question, but I guess if
you can answer my question then you will have the answer to that one.
Ralph
