cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <>
Subject Re: [Proposal] Creating better portal urls
Date Wed, 07 Sep 2005 06:43:29 GMT
Ralph Goers wrote:
> I beg to differ.  I actually implemented pageLabels based upon explicit 
> requirements I was given from our web authors. i.e. they wanted a syntax 
> like pageLabel=maintab1.subnavitem2.thirdnav1.  And while I will admit 
> that the event data passed to the portlet url is somewhat obscure, it is 
> very similar to that used by pluto (since I borrowed some of the logic 
> from them).
Ok, first of all, the current mechanism will stay in place and still
work. So nothing really changes - if you don't want to.

>>With the proposal we are able to have urls like
> And how would this look with three nav levels and a portlet url and the 
> fullscreen event?

>>And these urls are always valid, so the created events always make
>>sense. I think this currently only makes sense for the tab layout to
>>switch the tab and perhaps for some "main content" portlet displaying
>>the main content.
> I still don't understand why you want to do this.  All the plumbing is 
> there now.
Not exactly :) All I want is that I'm able to add the information to the
path of the url
and not as request parameters - and this only for some events where it
makes sense.

Now, to be honest I don't know what the best approach is, but most of
the portal users I know want "nice" urls so they can link from outside
the portal to some content inside the portal. And they don't want to use
request parameters for that :(

We talked a while ago about getting rid off the cocoon-portal-event
parameter with the event number and use a "serialized" information (with
the factory approach you mentioned), perhaps we should first have a look
into that again?

On a similar subject, can you please explain what the marshalling of the
events does? (I think you explained it already, but I can't remember; a
link would be fine as well).

Carsten Ziegeler - Open Source Group, S&N AG

View raw message