Rapha�l Luta wrote:
>
> 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.
Yes. I initially wanted to make Jetspeed HTTP non-specific. I didn't
want to be in the same position as Cocoon is now with 2.0. However I
got stuck and started using RunData not realizing that what I was really
doign is exposing the Servlet API.
Sometime soon I am probably going to only pass around non-Servlet
(changing the Interface). If would pass things like ParameterParser,
etc.
> - 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
Explain. What would hinder storage? I don't see this being an issue.
> - it prevents any information not keyed directly to portlets (via PortletConfig)
> from being passed to the Controller.
This already is passed to the controller.
portletcontrol.getPortlet().getPortletConfig().
:)
> 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 ?
I don't have any problems doign a PortletSet. This does solve some data
storage issues as we can store them
right in the PortletSet.
> 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 ?
PortletSet is cool. I am game.
> On a related note, but more likely to be addressed in v3.0 :
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 ?
I agree. A lot of resources can be wasted if we do it like this.
However I can't see any other way to do it. I would rather waste memory
on a web app than CPU. The problem with a getContent(PortletConfig) is
where do you put your content when you swap out a previously generated
content. It would waste a lot of CPU to regen everythign everytime.
You could put the content in memory but then we are back where we
started.
Note that with the servlet API as it already is you can tell the Factory
not to cache it. Thus if you have a web app that always changes or
would otherwise waste *tons* of memory just tell it not to cache, or
handle the caching portion yourself.
This might be an issue for developer docs. What do you think. I
Engineered it to do this but I am not sure it was obvious except if you
looked at the code... hmmm. It will be in there for 1.1.
Kevin
--
Kevin A Burton ([EMAIL PROTECTED])
http://relativity.yi.org
Message to SUN: "Please Open Source Java!"
"For evil to win is for good men to do nothing."
--
--------------------------------------------------------------
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]
