Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 81508 invoked from network); 6 Sep 2005 19:05:36 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 6 Sep 2005 19:05:36 -0000 Received: (qmail 67732 invoked by uid 500); 6 Sep 2005 19:05:33 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 67692 invoked by uid 500); 6 Sep 2005 19:05:32 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@cocoon.apache.org List-Id: Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 67679 invoked by uid 99); 6 Sep 2005 19:05:32 -0000 X-ASF-Spam-Status: No, hits=-10.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [209.237.227.194] (HELO [127.0.0.1]) (209.237.227.194) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 06 Sep 2005 12:05:32 -0700 Message-ID: <431DE8E8.8080300@apache.org> Date: Tue, 06 Sep 2005 21:07:20 +0200 From: Carsten Ziegeler User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: Cocoon-Dev Subject: [Proposal] Creating better portal urls X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N 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/