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.
WDYT?
Carsten
Ralph
