Carsten Ziegeler wrote:
Ralph Goers wrote:
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
FWIW, this is missing the PortletURLProviderEvent (I probably wasn't
clear when I said portlet url).
With page labels this is
http://my.great.portal.com/portal?pageLabel=MAINTAB.SUBITEM.SUBITEM2&javax.portlet.events=cocoon-portal-fs(X)&javax.portlet.events=url(portlet-data)
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
"javax.portlet.events=name(event data)".
Thanks
Carsten
Ralph
