You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Carsten Ziegeler <cz...@apache.org> on 2005/09/06 21:07:20 UTC
[Proposal] Creating better portal urls
The current portal creates urls like ...portal?cocoon-portal-event=XXX
for most links. There are some additional things in there, like the page
labels and the bookmark action and some events can create more readable
urls, but I think all of this has some disadvantages.
Now, I'm currently thinking of providing a general mechanism that
creates/uses "real" urls, like
.../main/weblogs or .../main/applications
without any additional parameter.
So, how could this work. What do you think of using this URL scheme:
.../OBJECT_ID_A/EVENT_INFO_FOR_OBJECT_A
So, in the example from above, the object with the id "main" gets an
event with the information "weblogs" or "applications". In this example
"main" is the main tab and the information tells the tab to switch to
that tab.
But there is more, you can add as many "events" to the url:
.../OBJECT_ID_A/EVENT_INFO_FOR_OBJECT_A/OBJECT_ID_B/EVENT_INFO_FOR_OBJECT_B...
So the url consists of key value pairs creating "more readable" urls.
For example: .../main/docs/page/news
This url switches to the docs tab and passes the info "news" to the page
coplet and this coplet then displays the news as its content.
These urls are easily bookmarkable.
Of course, for actions like minimizing etc. we still use url parameters.
Now, to make this work objects have to be made aware of this mechanism.
I'm thinking of some marker interfaces (with some functions) for layout
objects and coplets. I have no concrete idea how to implement it, but I
first want to discuss the idea before getting into implementation details :)
How does this sound?
PS: There will be one minor problem - all objects need a unique
identier. Currently you can have a layout object and a coplet instance
with the same identifier. But I think this is no real problem.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: [Proposal] Creating better portal urls
Posted by Ralph Goers <Ra...@dslextreme.com>.
Carsten Ziegeler wrote:
>Ralph Goers wrote:
>
>
>>Why? It seems cleaner to me to use parameters. The way it is
>>implemented now uses the javax.portlet restricted namespace and it
>>doesn't clutter up the url - which is typically used for navigation. I
>>thought about adding the stuff to the url, but in the end it seemed that
>>the url would just end up big and ugly.
>>
>>
>>
>See my reply to Sylvain - I don't think we should do this for *all*
>events, just for a few (like switching tab). This creates urls that are
>usable from outside the portal and this are "human rememberable" (nice
>word :) ).
>
>
Then I would suggest just making the few events that you want convertable.
>Carsten
>
>
Ralph
Re: [Proposal] Creating better portal urls
Posted by Carsten Ziegeler <cz...@apache.org>.
Ralph Goers wrote:
>
> Why? It seems cleaner to me to use parameters. The way it is
> implemented now uses the javax.portlet restricted namespace and it
> doesn't clutter up the url - which is typically used for navigation. I
> thought about adding the stuff to the url, but in the end it seemed that
> the url would just end up big and ugly.
>
See my reply to Sylvain - I don't think we should do this for *all*
events, just for a few (like switching tab). This creates urls that are
usable from outside the portal and this are "human rememberable" (nice
word :) ).
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: [Proposal] Creating better portal urls
Posted by Ralph Goers <Ra...@dslextreme.com>.
Carsten Ziegeler wrote:
>Ralph Goers wrote:
>
>
>>Did you look at the ConvertableEvent and ConvertableEventFactory? The
>>idea there was to allow events to be created using the information
>>provided in the request. You can see implementations of this in
>>FullScreenCopletEventFactory and PortletURLProviderFactory. The
>>ConvertableEventAspect creates the events. I only create the ones for
>>FullScreen and PortletURLProvider because they were required to get
>>JSR-168 portlets to work properly. I had intended to create more of them
>>but I haven't had the need.
>>
>>
>>
>Yepp, I know them - the mechanism I'm thinking of is similar (perhaps
>uses the same components), but the basic different is that the
>information is added to the path of the url and not as parameters.
>
>
Why? It seems cleaner to me to use parameters. The way it is
implemented now uses the javax.portlet restricted namespace and it
doesn't clutter up the url - which is typically used for navigation. I
thought about adding the stuff to the url, but in the end it seemed that
the url would just end up big and ugly.
Ralph
Re: [Proposal] Creating better portal urls
Posted by Carsten Ziegeler <cz...@apache.org>.
Ralph Goers wrote:
>
> Did you look at the ConvertableEvent and ConvertableEventFactory? The
> idea there was to allow events to be created using the information
> provided in the request. You can see implementations of this in
> FullScreenCopletEventFactory and PortletURLProviderFactory. The
> ConvertableEventAspect creates the events. I only create the ones for
> FullScreen and PortletURLProvider because they were required to get
> JSR-168 portlets to work properly. I had intended to create more of them
> but I haven't had the need.
>
Yepp, I know them - the mechanism I'm thinking of is similar (perhaps
uses the same components), but the basic different is that the
information is added to the path of the url and not as parameters.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: [Proposal] Creating better portal urls
Posted by Ralph Goers <Ra...@dslextreme.com>.
Carsten Ziegeler wrote:
>The current portal creates urls like ...portal?cocoon-portal-event=XXX
>for most links. There are some additional things in there, like the page
>labels and the bookmark action and some events can create more readable
>urls, but I think all of this has some disadvantages.
>
>Now, I'm currently thinking of providing a general mechanism that
>creates/uses "real" urls, like
>
>.../main/weblogs or .../main/applications
>
>without any additional parameter.
>
>So, how could this work. What do you think of using this URL scheme:
>.../OBJECT_ID_A/EVENT_INFO_FOR_OBJECT_A
>
>So, in the example from above, the object with the id "main" gets an
>event with the information "weblogs" or "applications". In this example
>"main" is the main tab and the information tells the tab to switch to
>that tab.
>
>But there is more, you can add as many "events" to the url:
>.../OBJECT_ID_A/EVENT_INFO_FOR_OBJECT_A/OBJECT_ID_B/EVENT_INFO_FOR_OBJECT_B...
>
>So the url consists of key value pairs creating "more readable" urls.
>For example: .../main/docs/page/news
>This url switches to the docs tab and passes the info "news" to the page
>coplet and this coplet then displays the news as its content.
>
>These urls are easily bookmarkable.
>
>Of course, for actions like minimizing etc. we still use url parameters.
>Now, to make this work objects have to be made aware of this mechanism.
>I'm thinking of some marker interfaces (with some functions) for layout
>objects and coplets. I have no concrete idea how to implement it, but I
>first want to discuss the idea before getting into implementation details :)
>
>How does this sound?
>
>PS: There will be one minor problem - all objects need a unique
>identier. Currently you can have a layout object and a coplet instance
>with the same identifier. But I think this is no real problem.
>
>Carsten
>
>
>
Did you look at the ConvertableEvent and ConvertableEventFactory? The
idea there was to allow events to be created using the information
provided in the request. You can see implementations of this in
FullScreenCopletEventFactory and PortletURLProviderFactory. The
ConvertableEventAspect creates the events. I only create the ones for
FullScreen and PortletURLProvider because they were required to get
JSR-168 portlets to work properly. I had intended to create more of them
but I haven't had the need.
Ralph
Re: [Proposal] Creating better portal urls
Posted by Carsten Ziegeler <cz...@apache.org>.
Andreas Hochsteger wrote:
> Do you mean something like mod_rewrite for Apache
> (http://httpd.apache.org/docs/2.0/mod/mod_rewrite.html)?
>
Hmm, similar but as a Java component - so you have to code the rewriting
and can't configure it.
The current LinkService can be used to do the conversion from current
portal urls to "nice urls", so you only have to provide a component that
does the reverse.
Carsten
>
> Carsten Ziegeler wrote:
>
>>Ralph Goers wrote:
>>
>>>Carsten Ziegeler wrote:
>>>
>>>
>>>
>>>>Ok, the more I think about it, I could imagine using a url pre and post
>>>>precessor. When a url (link) is created the usual way, a post processor
>>>>can change the url and for example create url path elements instead of
>>>>request parameters.
>>>>For an incomming event, the url pre processor does the other way round.
>>>>
>>>
>>>Can you give me a bit more detail on this? I'm not sure I have the
>>>picture. But it sounds like it is sort of like a transformer on the
>>>incoming and outgoing requests. That might be kind of cool. I can
>>>envision folks using that for other things, but I'm not sure.
>>>
>>
>>Yepp, exactly - it works like a transformer, it gets the original url,
>>portal?cocoon-portal-event=37 and creates a nice url (depending on
>>personal preferences for "nice") like "content.html" (or whatever).
>>The transformation should work without storing something into the user
>>session, so the nice urls can be used to link to the portal from
>>external applications/email whatever.
>>
>>Then the incomming url is transformed back - we can manage this without
>>any redirects happening (I think).
>>
>>Carsten
>>
>
>
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: [Proposal] Creating better portal urls
Posted by Andreas Hochsteger <e9...@student.tuwien.ac.at>.
Do you mean something like mod_rewrite for Apache
(http://httpd.apache.org/docs/2.0/mod/mod_rewrite.html)?
Andreas
Carsten Ziegeler wrote:
> Ralph Goers wrote:
>> Carsten Ziegeler wrote:
>>
>>
>>> Ok, the more I think about it, I could imagine using a url pre and post
>>> precessor. When a url (link) is created the usual way, a post processor
>>> can change the url and for example create url path elements instead of
>>> request parameters.
>>> For an incomming event, the url pre processor does the other way round.
>>>
>> Can you give me a bit more detail on this? I'm not sure I have the
>> picture. But it sounds like it is sort of like a transformer on the
>> incoming and outgoing requests. That might be kind of cool. I can
>> envision folks using that for other things, but I'm not sure.
>>
> Yepp, exactly - it works like a transformer, it gets the original url,
> portal?cocoon-portal-event=37 and creates a nice url (depending on
> personal preferences for "nice") like "content.html" (or whatever).
> The transformation should work without storing something into the user
> session, so the nice urls can be used to link to the portal from
> external applications/email whatever.
>
> Then the incomming url is transformed back - we can manage this without
> any redirects happening (I think).
>
> Carsten
>
Re: [Proposal] Creating better portal urls
Posted by Carsten Ziegeler <cz...@apache.org>.
Ralph Goers wrote:
>
> Carsten Ziegeler wrote:
>
>
>>Ok, the more I think about it, I could imagine using a url pre and post
>>precessor. When a url (link) is created the usual way, a post processor
>>can change the url and for example create url path elements instead of
>>request parameters.
>>For an incomming event, the url pre processor does the other way round.
>>
>
> Can you give me a bit more detail on this? I'm not sure I have the
> picture. But it sounds like it is sort of like a transformer on the
> incoming and outgoing requests. That might be kind of cool. I can
> envision folks using that for other things, but I'm not sure.
>
Yepp, exactly - it works like a transformer, it gets the original url,
portal?cocoon-portal-event=37 and creates a nice url (depending on
personal preferences for "nice") like "content.html" (or whatever).
The transformation should work without storing something into the user
session, so the nice urls can be used to link to the portal from
external applications/email whatever.
Then the incomming url is transformed back - we can manage this without
any redirects happening (I think).
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: [Proposal] Creating better portal urls
Posted by Ralph Goers <Ra...@dslextreme.com>.
Carsten Ziegeler wrote:
>Ok, the more I think about it, I could imagine using a url pre and post
>precessor. When a url (link) is created the usual way, a post processor
>can change the url and for example create url path elements instead of
>request parameters.
>For an incomming event, the url pre processor does the other way round.
>
>WDYT?
>
>Carsten
>
>
>
Can you give me a bit more detail on this? I'm not sure I have the
picture. But it sounds like it is sort of like a transformer on the
incoming and outgoing requests. That might be kind of cool. I can
envision folks using that for other things, but I'm not sure.
Ralph
Re: [Proposal] Creating better portal urls
Posted by Carsten Ziegeler <cz...@apache.org>.
Ok, the more I think about it, I could imagine using a url pre and post
precessor. When a url (link) is created the usual way, a post processor
can change the url and for example create url path elements instead of
request parameters.
For an incomming event, the url pre processor does the other way round.
WDYT?
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: [Proposal] Creating better portal urls
Posted by Ralph Goers <Ra...@dslextreme.com>.
Carsten Ziegeler wrote:
>Ralph Goers wrote:
>
>
>>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".
>>
>>
>Yepp, this is more or less my point :)
>
>
>>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?
>>
>>
>Think of a forrest site done with the portal, you have some navigation
>coplets,
>perhaps some news coplets and the big area is the content copletshowing
>the current document. Clicking a link from the navigation toggles the
>content inside the content coplet. CHanging the content is done via
>events, the id of the content coplet is "page" and index.html is the
>document to display.
>
>
Unfortunately, I have no familiarity with forrest, but I think I
understand. IIUC, you are basically saying that page/index.html is data
for the target of the nav. I'm not crazy about this syntax, but
whatever floats your boat. Since it seems the functionality is pretty
much the same between the two then the best option is to divorce the
functionality from how it appears in the request. Then everybody can
just do their own thing.
>
>
>
>Ah, ok, now you mentioned that you need marshalling in order to
>get JSR 168 portlets running. I have several JSR 168 portlets running
>without marshalling. Do you have a test case where this doesn't work,
>cause I think it should work without marshalling.
>
>
http://issues.apache.org/bugzilla/show_bug.cgi?id=33091
Unfortunately, I don't have a portlet handy that demonstrates this. I
guess you can try doing a page reload with your portlets and see what
happens.
Ralph
>Carsten
>
>
Re: [Proposal] Creating better portal urls
Posted by Carsten Ziegeler <cz...@apache.org>.
Ralph Goers wrote:
> 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".
Yepp, this is more or less my point :)
>
> 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?
Think of a forrest site done with the portal, you have some navigation
coplets,
perhaps some news coplets and the big area is the content copletshowing
the current document. Clicking a link from the navigation toggles the
content inside the content coplet. CHanging the content is done via
events, the id of the content coplet is "page" and index.html is the
document to display.
>
> 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)".
>
Ah, ok, now you mentioned that you need marshalling in order to
get JSR 168 portlets running. I have several JSR 168 portlets running
without marshalling. Do you have a test case where this doesn't work,
cause I think it should work without marshalling.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: [Proposal] Creating better portal urls
Posted by Ralph Goers <Ra...@dslextreme.com>.
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
Re: [Proposal] Creating better portal urls
Posted by Carsten Ziegeler <cz...@apache.org>.
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/
Re: [Proposal] Creating better portal urls
Posted by Ralph Goers <Ra...@dslextreme.com>.
Carsten Ziegeler wrote:
>Sylvain Wallez wrote:
>
>
>>Don't know much about the portal, but this proposal triggered a few
>>thoughts.
>>
>>First of all, using path elements to identify objects and actions, and
>>possibly allowing to have multiple pairs is likely to cause problems by
>>forbidding the use of relative URLs for links, images, etc. A separator
>>other than "/" would solve this.
>>
>>
>>
>In general true, but not inside the portal - the portal creates or
>rewrites all urls. So the portal is taking care of this.
>
>
>
>>Now about bookmarking. You speak about "sending events". Does it make
>>sense to bookmark a URL that sends an event? What if the bookmark is
>>displayed again later in a system state where that event doesn't make sense?
>>
>>
>The current bookmark feature does exactly the same. Now the proposal is
>not about all events that are possible in the portal. It's just for the
>most common ones, like switching the tab.
>Now, users of the portal want "readable urls", they want something like
>http://my.great.portal.com/index.html or
>http://my.great.portal.com/news.html
>(If *we* like the .html at the end or not is not the question.)
>
>Currently the urls look like
>http://my.great.porta.com/portal?cocoon-portal-event=27
>Even with page labels the url is not that much better.
>
>
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).
>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?
>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.
>Carsten
>
>
Ralph
Re: [Proposal] Creating better portal urls
Posted by Carsten Ziegeler <cz...@apache.org>.
Sylvain Wallez wrote:
> Don't know much about the portal, but this proposal triggered a few
> thoughts.
>
> First of all, using path elements to identify objects and actions, and
> possibly allowing to have multiple pairs is likely to cause problems by
> forbidding the use of relative URLs for links, images, etc. A separator
> other than "/" would solve this.
>
In general true, but not inside the portal - the portal creates or
rewrites all urls. So the portal is taking care of this.
> Now about bookmarking. You speak about "sending events". Does it make
> sense to bookmark a URL that sends an event? What if the bookmark is
> displayed again later in a system state where that event doesn't make sense?
The current bookmark feature does exactly the same. Now the proposal is
not about all events that are possible in the portal. It's just for the
most common ones, like switching the tab.
Now, users of the portal want "readable urls", they want something like
http://my.great.portal.com/index.html or
http://my.great.portal.com/news.html
(If *we* like the .html at the end or not is not the question.)
Currently the urls look like
http://my.great.porta.com/portal?cocoon-portal-event=27
Even with page labels the url is not that much better.
With the proposal we are able to have urls like
http://my.great.portal.com/page/index.html
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.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: [Proposal] Creating better portal urls
Posted by Ralph Goers <Ra...@dslextreme.com>.
Sylvain Wallez wrote:
> Don't know much about the portal, but this proposal triggered a few
> thoughts.
>
> First of all, using path elements to identify objects and actions, and
> possibly allowing to have multiple pairs is likely to cause problems
> by forbidding the use of relative URLs for links, images, etc. A
> separator other than "/" would solve this.
I don't like the idea of using the URL for this.
>
> Now about bookmarking. You speak about "sending events". Does it make
> sense to bookmark a URL that sends an event? What if the bookmark is
> displayed again later in a system state where that event doesn't make
> sense?
There are cases where it does make sense. Often the portlets are
somewhat generic. The events can provide them the information they need
to know what to do.
>
> Sylvain
Ralph
Re: [Proposal] Creating better portal urls
Posted by Sylvain Wallez <sy...@apache.org>.
Carsten Ziegeler wrote:
>The current portal creates urls like ...portal?cocoon-portal-event=XXX
>for most links. There are some additional things in there, like the page
>labels and the bookmark action and some events can create more readable
>urls, but I think all of this has some disadvantages.
>
>Now, I'm currently thinking of providing a general mechanism that
>creates/uses "real" urls, like
>
>.../main/weblogs or .../main/applications
>
>without any additional parameter.
>
>So, how could this work. What do you think of using this URL scheme:
>.../OBJECT_ID_A/EVENT_INFO_FOR_OBJECT_A
>
>So, in the example from above, the object with the id "main" gets an
>event with the information "weblogs" or "applications". In this example
>"main" is the main tab and the information tells the tab to switch to
>that tab.
>
>But there is more, you can add as many "events" to the url:
>.../OBJECT_ID_A/EVENT_INFO_FOR_OBJECT_A/OBJECT_ID_B/EVENT_INFO_FOR_OBJECT_B...
>
>So the url consists of key value pairs creating "more readable" urls.
>For example: .../main/docs/page/news
>This url switches to the docs tab and passes the info "news" to the page
>coplet and this coplet then displays the news as its content.
>
>These urls are easily bookmarkable.
>
>Of course, for actions like minimizing etc. we still use url parameters.
>Now, to make this work objects have to be made aware of this mechanism.
>I'm thinking of some marker interfaces (with some functions) for layout
>objects and coplets. I have no concrete idea how to implement it, but I
>first want to discuss the idea before getting into implementation details :)
>
>How does this sound?
>
>
Don't know much about the portal, but this proposal triggered a few
thoughts.
First of all, using path elements to identify objects and actions, and
possibly allowing to have multiple pairs is likely to cause problems by
forbidding the use of relative URLs for links, images, etc. A separator
other than "/" would solve this.
Now about bookmarking. You speak about "sending events". Does it make
sense to bookmark a URL that sends an event? What if the bookmark is
displayed again later in a system state where that event doesn't make sense?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director