Carsten Ziegeler wrote:
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.
Ouch. Well I could look into fixing that tomorrow. It needs to work in
2.1 and I presume the changes below are only going in trunk.
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
portlets).
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?
Well, JSR-168 (almost) defines NORMAL, MAXIMIZED and MINIMIZED.
Unfortunately, both full-screen and max-paged meet the definition of
MAXIMIZED so it isn't clear what behavior a portlet should exhibit in
that case. In addition, JSR-168 allows us to define other window
states. So I would suggest that whatever window states are supported
that they be done in such a way that they can eventually be used by
JSR-168 portlets as well as coplets.
Hmm, I thought if preferences are changing, the coplet instances data
are only saved and not the layout?
After looking at the code I guess your right - we only write out the
coplet instances data. That isn't a problem for me now, but I imagine it
will be for some users.
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.
As I recall this was partly an artifact of the way that pluto stores
preferences. I believe pluto starts the process by calling
PortletEntityImpl.store(). So unless we keep track of the parts that
have changed ourselves we don't know what has changed and so we write
the whole thing. However, I believe it is worse than that because we end
up using Castor to generate the XML and it, of course, is going to want
to generate the whole document.
Ralph
