cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <>
Subject Re: svn commit: r326626 - in /cocoon/blocks: portal-sample/trunk/samples/conf/ portal/trunk/ portal/trunk/java/org/apache/cocoon/portal/ portal/trunk/java/org/apache/cocoon/portal/aspect/impl/ portal/trunk/java/org/apache/cocoon/portal/coplet/ portal/trunk...
Date Wed, 19 Oct 2005 19:32:10 GMT
Ralph Goers wrote:

> I've looked over the latest check-in and it occured to me that if you
> are going to make all events be convertable that:
> a) we won't need the marshall events flag anymore,

Yeah, I removed them  :)

> b) It should end up that only the events needed to process the current
> request will end up in the decode list of the DefaultEventConverter. The
> encode list shouldn't be needed as the decode list would be populated at
> the beginning of the request.

Hmm, yes, I'll have a look at it.

> c) The extra logic I added to manage events by page label (i.e.
> PageLabelEventConverter) isn't needed for the same reason.

I haven't look at the page label handling yet. But if you think that you
can simply it (by removing  :)  ) just go ahead.

> Frankly, if we can make all events convertable I think it should be done
> and just become the behavior of how the portal manages urls.

I totally agree.

> I have a concern over the hascode that is used in the
> DefaultEventConverter.  Although it may not be likely, hash algorithms
> can return duplicate values so this is not guaranteed to always work.

Yes, you can configure a mapping on the event converter and use more
readable keys:
<mapping name="sizing" event-class="o.a.c.p.SOMETHING"/>

In fact, I'm trying to clean up the "mess" we created three years ago
when we developed the portal...

One thing is the sizing and the full screen handling. I removed
yesterday the extra full screen event/handling. 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 recently.
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.
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 for preserving the navigation in 2.2
again  :)  and implement this static stuff which is a little bit more
flexible and general.

I think I'll have a look at page label stuff next week and see if we can
integrate it even better in the current 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 - and I think this is the
way how it should have been in the first place.
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...

Carsten Ziegeler - Open Source Group, S&N AG

View raw message