cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <>
Subject Re: [Proposal] Creating better portal urls
Date Wed, 07 Sep 2005 07:23:33 GMT

Carsten Ziegeler wrote:

>Ralph Goers wrote:
>>And how would this look with three nav levels and a portlet url and the 
>>fullscreen event?
FWIW, this is missing the PortletURLProviderEvent (I probably wasn't 
clear when I said portlet url).

With page labels this is

Also, I thought you were proposing adding the events to the url as 
well?  If you are not, then I believe all we are discussing is whether 
nav items are in the url or in a request parameter.  That just becomes a 
question of which we think is "prettier". Under the covers the 
implementation has to be pretty similar.  IMO, which isn't worth much in 
this case, the url you provided above is kind of ugly.  Also, what is 
the page/index.html about?

>>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 :(
Why?  The folks I work with are pretty sharp (I admit, a lot more 
educated than me when it comes to designing web sites - I'm a framework 
guy), and they were quite happy with 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?
My approach was to use convertable events. The issue is that we 
currently allow events to be created in one request and retrieved in 
another. This just isn't really possible with a fully "serialized" 
approach. You always have to "remember" something, which isn't a 
problem, and then delete it when it isn't needed any more (which we 
almost never know).

>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).
Marshalling does exactly what we have been talking about.  If 
marshalling is not enabled than the events show up in the request with 
request ids as you are used to. If marshalling is enabled then any 
convertable events appear in the request in their serialized form (see 
the example I gave above). To create new Convertable events you just 
need to implement the Convertable interface on an event, create a 
factory for the event and then add the factory class name and the event 
"name" to the list in the ConvertableEventAspectSelector. Events are 
always created as request parameters of the form 
" data)".


View raw message