[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xml-cocoon-dev
Subject:    Re: [Proposal] Creating better portal urls
From:       Carsten Ziegeler <cziegeler () apache ! org>
Date:       2005-09-07 6:43:29
Message-ID: 431E8C11.1010104 () apache ! org
[Download RAW message or body]

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
>>http://my.great.portal.com/page/index.html
>> 
>>
> 
> And how would this look with three nav levels and a portlet url and the 
> fullscreen event?
> 
http://my.great.portal.com/main/MAINTAB/sub1/SUBITEM/sub2/SUBITEM2/page/index.html?cocoon-portal-fs=X


> 
>>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).

Thanks
Carsten
-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
[prev in list] [next in list] [prev in thread] [next in thread]