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

List:       xml-cocoon-dev
Subject:    Re: [Proposal] Creating better portal urls
From:       Sylvain Wallez <sylvain () apache ! org>
Date:       2005-09-06 20:33:19
Message-ID: 431DFD0F.8090604 () apache ! org
[Download RAW message or body]

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

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