cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <>
Subject Re: pageLabel urls
Date Wed, 19 Oct 2005 19:34:58 GMT
Apologies to the list. This thread was started off-list but really 
belongs here.

Carsten Ziegeler wrote:

>Hi Ralph,
>Ralph Goers wrote:
>>OK.  I did notice that you got rid of the fullscreen event yesterday.  
>>That was a good thing.  
>Yepp, I'm trying to clean up the "mess" we created three years ago when
>we developed the portal...
>>Also, I added a configuration option to
>>PortalManagerImpl to support having the navigation when a portlet is 
>>maximized (i.e. fullscreen).  Personally, I think that should be the 
>>default in 2.2 but I left it off to maintain compatibility - even though 
>>I can't imagine anyone actually wanting the default behavior.  WDYT?
>Yes, I saw this - now, for some of our customers "real" full screen
>without navigation etc. makes sense. They have very hugh forms and a lot
>of information and they want to see it all at once in one portlet...and
>then you simply use all available space for it.
>Now my idea is to support four window states in the Cocoon portal:
>minimized, normal, max-page and full-screen (don't know if the names of
>the last two items are good or not). Now full-screen is real full-screen
>:) and max-page is what you have implemented
>The basic idea for max-page is that you mark your layout with static
>parts, so for example the navigation is static, or a news portlet is
>static. Now if you want to display a portlet in max-page mode, the non
>static parts make space for this portlet and only the static parts and
>the max-page portlet are displayed.
I think it would be OK to mark coplets as static, but I think the nav 
should either just be there or not. I don't see the point in having to 
add a static attribute to all the named items.  This would also be 
pretty easy to implement. We could get rid of the entry layout altogther 
and just use attributes on the "base layouts" (i.e. coplet, frame) to 
figure out which ones to display. 

>We actually had this feature three years ago when we started with the
>new portal engine but removed it later on because it had a serious
>performance impact. Some months after we removed it, I had a great idea
>how to do it without loosing performance; unfortunately I never had time
>to implement it and today I don't know how this idea really was...
>So my plan is to remove your config in 2.2 again :) and implement this
>static stuff which is a little bit more flexible and general.
>>As far as the page label stuff goes, I purposely didn't integrate it 
>>into other components so that it would be easy to maintain.
>Yeah, that's ok.
>>compatibility. But if you can figure out a better way to integrate it or 
>>if you think that should just be the way it works then I'm OK with that.
>I think I'll have a look at page label stuff next week, so we'll see.
>I just committed a newer version of the url handling. I think when we
>created the event conversion stuff, we did a mistake by assuming that
>events are always converted to request parameters. Now, I changed this
>and e.g. a convertable event now just converts it's data to a string.
>The event is not aware if a request parameter is used (or which) or if
>the data will be part of the uri or whatever.
>Then the event converter converts an event either into an internal
>format (the numbering) or if it's an convertable event, that
>representation is used.
>Finally the link service uses the data from the converter and currently
>creates request parameters with the parameter name
>"cocoon-portal-event". So, I removed the marshalling configuration as we
>now always marshal and I also removed some other stuff, like the
>convertable event factory. Now the event class itself converts the data
>back to the event. This avoids the additional configuration of the
>factories in the xconf.
>I think there shouldn't be any problems with JSR 168 portlets anymore,
>as request parameters starting with "cocoon-portal-" are not forwarded
>to the portlet. They are filtered. But I think we have to test this.
I would prefere using "javax.portlet.event" instead of 
"cocoon-portal-event" as javax.portlet is restricted for our use by JSR 
168, so there should never be a name clash with anything else.


View raw message