cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <>
Subject Re: svn commit: r330329 - in /cocoon/blocks/portal/trunk/java/org/apache/cocoon/portal: coplet/ layout/ layout/renderer/aspect/impl/ layout/renderer/impl/ persistence/castor/
Date Thu, 03 Nov 2005 07:54:24 GMT
Ralph Goers wrote:
> And what about the case that I added support for - full screen with all 
> the navigation still present?
Actually, your changes broke the full screen feature if no tab is
available. If you look at the current portal demo, full screen does not
work anymore in the anonymous section as there is no tab.

> Or is that what you are calling max-paged
> (I get realy confused by this since the default 2.1 behavior is 
> min/normal/full-screen-no-nav)?  
The new possibilities are min/norma/full-screen-no-nav/max-paged where
max-paged is a full-screen with static parts (= navigation and important
> Frankly, the static layout thing sounds 
> like it could get to be quite a pain. I really don't want to have to add 
> an attribute on every single tab to say it should always be shown.
Yes, for sure. We will have default values for each layout object. And
the default for a tab will be static=true. So actually you shouldn't
have to add an attribute at all.
I suggest, just give me some more days to implement this stuff. Then we
all can have a look at it and decide if it's a good thing or if it's
crap. And then perhaps we see what we really need.
But as I said, we have the use case for full-screen (= one single coplet
without any navigation) and max-paged. Perhaps max-paged is a wrong or
misleading term?

> In
> all the sites we will be delivering we will always want all the 
> navigation available.
> On a separate topic, it occurred to me that there is a problem with 
> saving the layout.  We will be dynamically generating layouts from a 
> bunch of pieces. A user may or may not have a portlet on a page or they 
> might not have a page.  This will work fine, but if portlet preferences 
> are modified the whole layout gets written, not just the part specific 
> to the portlet.  That would mean the user's layout could then no longer 
> be dynamically generated.
Hmm, I thought if preferences are changing, the coplet instances data
are only saved and not the layout?
But you're right that it's not good to save the whole bunch of data. We
should provide the information about what changed to the persistence
layer and it's then up to the layer to decide to save the whole profile
or just the changed information.

Carsten Ziegeler - Open Source Group, S&N AG

View raw message