portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Santiago Gala <sg...@hisitech.com>
Subject Re: [PATCH] org.apache.jetspeed.portal.BasePortletSet.sortPortlet Set()
Date Thu, 04 Apr 2002 10:11:45 GMT
Glenn Golden wrote:

>The sorting must be done for customization, which the customizer *could*
>(and does) do.

Just random thoughts. I copy a snippet from you previous patch:

+            // process each portlet in portlets
+            for (int i = 0; i < psize; i++)
                 Portlet p = (Portlet)portlets.elementAt(i);
                 int pos = p.getPortletConfig().getPosition();
-                if ( (pos>=0) && (pos!=i) )
+                // if the portlet has a good position, place it in the list there
+                if (   (pos >= 0)
+                    && (pos < psize)
+                    && (plist.get(pos) == null))

There we can see one of the evil API interactions that we have now: We 
query a portlet for its position ( p.getPortletConfig().getPosition() ). 
But the portlet should not know anything about global layout! A 
PortletConfig stored in a portlet is calling for problems.

Furthermore, PortletConfig.setPosition() is only called (AFAIK) in the 
same class, in addPortlet(). So we are storing the layout state in a 
different object, only to ask for it later, in the controllers and 
PortletSet layout algorithm.

As Raphael said, we should kill the current PortletConfig (the 
PortletConfig in IBM API 2 proposal is a completely different beast, I 
don't know about current proposals), and have the Entry as additional 
context for the getContent() call.

But, again, let us act slowly. Let us think about better separation of 

As I said, this is random thought, so don't expect conclusions... :)

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

View raw message