[xwiki-dev] Clean URLs - Anyone knows why we have /bin/ in XWiki URLs?
Sergiu Dumitriu
sergiu.dumitriu at gmail.com
Mon Feb 12 21:52:23 CET 2007
On 2/12/07, Vincent Massol <vincent at massol.net> wrote:
>
> Hi,
>
> Some user (Jerome Lacoste) has commented to me that XWiki URLs are a
> bit too complex and should be simplified and cleaned as much as
> possible. I agree with him.
I also agree, and there's a task for this somewhere in my queue.
Take for example: http://www.xwiki.org/xwiki/bin/view/Main/WebHome
>
> Wouldn't it be nice is this was simplified to http://www.xwiki.org/
> Main/WebHome?
Yes, but it's going to be tough.
This would mean view is the action by default.
>
> I guess we could have: http://www.xwiki.org/Main/WebHome?action="view|
> edit|..." with view being the default.
I (and also some search engines) don't like this. It reminds me of those
websites consisting of one page only and a few params, like
www.mysite.com?page=78. Anyway, for other actions except view, we can decide
on whatever method to specify the action.
The /xwiki/ part will be able to be removed once we fix the jira
> issue about removing the hardcoding about it.
I think the hardcoded urls have been fixed, but I wouldn't recommend having
the default package configured as the ROOT webapp. Instead, we should
document how to make xwiki respond to the URL without /xwiki/, either by
deploying the application as the ROOT webapp, or by using apache+mod_jk+URL
rewriting. This is because xwiki might live in a crowded environment, where
the ROOT application already exists.
That leaves the /bin/ path. I'm not sure why it's there and what it's
> doing. I can see some hardcoded /testbin/ in the code but I thin this
> is probably some leftover that we should remove (or do differently).
The /bin/ part is needed for sending requests to struts, and the /view part
is needed for sending requests to the ViewAction. XWiki works fine without
/view/, what needs to be changed is the URLFactory that generates URLs.
Removing /bin/ is a bit trickier, since the container must know which
requests to pass to struts and which requests to serve as plain documents
(what's the difference between /Skins/MySkin and /skins/default/style.css
?). But for removing the /bin/ part, we can do this:
- send requests for / to struts
- remap existing directories to a simple directory listing / file retrieval
servlet. The default one should do fine, but I don't know (didn't find) a
way to specify a starting directory, since if we map it to /skin/, it will
serve files not from the skin directory, but from the root directory. And if
we don't want to explicitly map each directory, we could have only one
action ( /files/ for example) which calls this servlet, and all the problems
are solved. We just need to modify the same URLFactory.
So what's the reason for /bin/?
>
> Thanks
> -Vincent
>
So, to summarize:
- /xwiki/ should be there in the default package, but we need to document
how it can be removed if needed/wanted.
- /bin/ can be removed
- /view/ can be removed
- /edit/inline/viewrev/download ... can be replaced with something else, but
I think they should stay there
- /files/ should be added for serving files on the local file system
- The code generating URLs should be modified. Anyway, with the
architectural change, a complete recheck/rewrite of the various URL modules
should be performed.
Sergiu
--
http://purl.org/net/sergiu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.xwiki.org/pipermail/devs/attachments/20070212/f8208a2b/attachment.htm
More information about the devs
mailing list