Over the week-end, I've converted the Jetspeed sources to a TogetherJ project
(at last) so I had a better view at the Jetspeed architecture.
I have 2 concerns about the global architecture currently:
- the use of RunData everywhere, but I think Kevin agrees this is not the best
option.
- the use of Portlets[] in a lot a API calls (especially at the controller
level)
This is really wrong because:
- it exposes an implementation detail which may constraint/hinder future
storage optimisation
- it prevents any information not keyed directly to portlets (via PortletConfig)
from being passed to the Controller.
This raises issues such as:
- Where can my controller get user-specific configuration options
(for example the number of columns to be displayed) ?
- How can I use the panes mentioned in the Portlet Markup thread ?
- ...
Proposal:
Change the API so that instead of using portlets[] in the methods signature
we use a new interface which would encapsulate the array and maybe
provide iterators or keyed access to the servlets. I'm yet to come with
a good enough name for the interface (since Content is already used...), maybe
PortletSet ?
On a related note, but more likely to be addressed in v3.0 :
Currently the Portlet API assume most work will be done by the portlet in
its init method using a specific PortletConfig. This, as far as I understand the
model, leads to create one portlet instance/PortletConfig defined in the
configuration files. This could lead to a huge waste of resources when there
are many concurrent users.
I think the portlet API should allow each Portlet to be recognizable as a
stateless portlet and define a getContent(PortletConfig pc) method.
This way we will be able to write sophisticated Factories which will create
pools
of stateless portlets to be reused by different requests.
I even wonder if statelessness can not be mandatory for all portlets except
thoes that are defined as applications.
Issue: does this break caching ?
OK, back to work... :(
--
Rapha�l Luta - [EMAIL PROTECTED]
--
--------------------------------------------------------------
Please read the FAQ! <http://java.apache.org/faq/>
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/main/mail.html>
Problems?: [EMAIL PROTECTED]
