portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glenn Golden <ggol...@umich.edu>
Subject RE: Portlet.getID() returning NULL
Date Fri, 10 May 2002 02:29:42 GMT
David -

Nice to hear your "voice" again!

Damn about getID().  All my code is based on this!  I have to fix it.

The question is how far do we go now.

How much of this do you understand and can layout / have a chat about?

I hope that I can preserve the APIs as they are - and just fix the
implementations.

For example, I see that at least some, if not all, of the code that gets a
portlet class to process a request go through the
JetspeedPortletFactoryService.  There is an "entry", i.e. stuff from the
psml, and we need a class to do the work, right?  Then there's the caching,
which looks pretty bad as is, but if you turn it off, getID() is completely
gone!

Is there some other major way that "portlet" class objects are created /
found?

I propose fixing the portlet problem by collecting the various parts
together and placing them behind the portlet api.  For example, the getID()
is really and more properly the psml entry's getId(), right?  So, at compose
time, when the portlet want's it's getID(), this becomes just a cover to the
getId() of the associated Entry.

The factory would find or create an instance of the portlet class, and then
pack it up with the entry and anything else we want to clean up here
(registry information would be good) into some sort of wrapped up object -
the portlet instance burrito.  The base portlet implementations, such as
abstract portlet, would be modified to know what's portlet proper and what's
in a various associated object and satisfy the portlet API that way.

This taco bell creation would last only as long as the request, and then be
discarded.  The portlet class that is used in this mix could be cached, and
could be used by many concurrent threads at once, each one mixed with a
different (perhaps) entry and registry set.

Ok, so this needs work, but I think it's a promising immediate fix, and I
need to do this NOW!

We preserve the Portlet API.  We introduce a new object that is used in
request rendering, which is this combination of multi-threaded persistent
cached (or singleton, for that matter) Portlet class with the right mix of
registry and psml stuff to make it a portlet instance (i.e. a particular
placement of the portlet on the particular page).  In fact, the portlet
class, the registry information for that portlet, and the psml entry for
that portlet instance can all be multi-use multi-threaded and singleton
(very efficient); only the combination of the three is done for each portlet
instance to be rendered for each request. 

I'll keep working on this idea, but I'd like some feedback early...

Thank!

- Glenn

--------------------------------------------
Glenn R. Golden, Systems Research Programmer 
University of Michigan School of Information
ggolden@umich.edu               734-615-1419
--------------------------------------------


> -----Original Message-----
> From: David Sean Taylor [mailto:david@bluesunrise.com] 
> Sent: Thursday, May 09, 2002 12:29 PM
> To: 'Jetspeed Developers List'
> Subject: RE: Portlet.getID() returning NULL
> 
> 
> The portlet getID() is broken as is.
> We are currently setting the instance id from the PSML entry (portlet
> instance) onto the concrete portlet class.
> This is not an acceptable solution, although it does seem to 
> work in low volume scenarios (like a single developer working 
> alone :).
> 
> The key to getting this to work is to refactor the 
> aggregation code (PortalToolkit), factor out PortletConfig 
> and return portlet instances in the generated PortletSets, 
> not portlets. When I say portlet instances, in the current 
> impl this is org.apache.jetspeed.om.Entry.
> 
> I looked into doing this a few weeks ago, but I estimated the 
> work and didn't have enough cycles.
> 
> 
> > -----Original Message-----
> > From: Glenn Golden [mailto:ggolden@umich.edu]
> > Sent: Thursday, May 09, 2002 9:13 AM
> > To: Jetspeed-Dev (jetspeed-dev@jakarta.apache.org)
> > Subject: Portlet.getID() returning NULL
> > 
> > 
> > I'm investigating a situation where a portlet given to the
> > VelocityPortletAction has a null id value.  This occurs in a 
> > request that is fast on the heals of a prior request - the 
> > prior request did this:
> > 
> > portlet.setAttribute(...
> > 
> > After the setAttribute, the next request comes up with a good
> > name, but no id!
> > 
> > Anybody happen to know what might be going on here?
> > 
> > Thanks.
> > 
> > - Glenn
> >  
> > --------------------------------------------
> > Glenn R. Golden, Systems Research Programmer
> > University of Michigan School of Information
> > ggolden@umich.edu               734-615-1419
> > --------------------------------------------
> > 
> > 
> > --
> > To unsubscribe, e-mail:   
> > <mailto:jetspeed-dev-> unsubscribe@jakarta.apache.org>
> > For
> > additional commands, 
> > e-mail: <mailto:jetspeed-dev-help@jakarta.apache.org>
> > 
> > 
> 
> 
> 
> --
> To unsubscribe, e-mail:   
> <mailto:jetspeed-dev-> unsubscribe@jakarta.apache.org>
> For 
> additional commands, 
> e-mail: <mailto:jetspeed-dev-help@jakarta.apache.org>
> 

--
To unsubscribe, e-mail:   <mailto:jetspeed-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:jetspeed-dev-help@jakarta.apache.org>


Mime
View raw message