"Kevin A. Burton" wrote:
>
> > - 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.
>
For example, if we have a lot of named portlets, an Hashtable might be better
than straight array, also providing an iterator on the portlet set never
hurts...
> > - 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().
>
> :)
>
That's exactly my point ! You have to use a getPortlet(), you can't retrieve
anything that's not keyed to a portlet (for example the num of columns to be
displayed for the defaultcontroller...)
>
> > 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.
>
The problem with this name is twofold:
- if it's a XXXSet, then it people may expect it to extend the java.util.Set
interface. Do we really want to implement this interface on our object ?
(I'd say yes)
- what if we want to use this object to allow the controller to retrieve a
Config object:
PortletSet.getControllerConfig() or PortletSet.getPanes() doesn't ring so well
to me...
> > On a related note, but more likely to be addressed in v3.0 :
>
> v3.0??? :)
>
Hey, you gotta plan ahead... ;) Anyway, since we release often, v3.0 will be
before 2001 :P
> > 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.
>
Well, the way I would see the process is:
Class X (for example PortletControl) needs a Portlet PO with config PC:
Call PortletFactory.getPortlet(PO,PC)
- if PO declared stateful portlet:
- check if CacheHandleManager has an instance created and
return it
- else create a new PO with PC.
- if PO stateless:
- get a PO from available pool and return it
Call ContentCacheManager.getContent(PO,PC)
- if content already generated, get it from store (either memory, file,
DB, etc...) and return it
- else call Portlet.getContent(PC)
- if PO stateful, getContent(PC) <=> getContent()
- else renders content with PC info.
The advantages of this method over the one currently implemented is that
ContentCacheManager can implement consistently any caching strategy, such
as storing the rendered content on disk, which the indivdual portlets
can't.
> 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.
>
I agree that WebApps should be left from the caching system as they may have
very complex operation.
> 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.
>
I certainly feel some developer docs is needed to understand Jetspeed
(and turbine) architecture, esp since the interfaces are still somewhat in
flux. Do you have some kind of OMT/UML schemas for Jetspeed available or should
we put this the TODO list ?
--
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]
