Clean URLs - Anyone knows why we have /bin/ in XWiki URLs?
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. 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? 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. The /xwiki/ part will be able to be removed once we fix the jira issue about removing the hardcoding about it. 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). So what's the reason for /bin/? Thanks -Vincent ___________________________________________________________________________ Yahoo! Mail r�invente le mail ! D�couvrez le nouveau Yahoo! Mail et son interface r�volutionnaire. http://fr.mail.yahoo.com
On 2/12/07, Vincent Massol <[email protected]> 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
The issue with mapping static file is what stopped me from getting rid of the "bin". It's sad to need a servlet for this. The "/bin" can be renamed in "/xwiki" Concerning the /xwiki/ removing it creates some issues with some absolute URL (same problem when the webapp is not named xwiki) Since we are talking about URLs, what would be cool is to have simple mod_rewrite like functionnality in XWiki also to allow to rewrite /123 into /Main/MyScript?id=123 Ludovic Sergiu Dumitriu a écrit :
On 2/12/07, *Vincent Massol* <[email protected] <mailto:[email protected]>> 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 <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 <http://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 ------------------------------------------------------------------------
-- You receive this message as a subscriber of the [email protected] mailing list. To unsubscribe: mailto:[email protected] For general help: mailto:[email protected]?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
-- Ludovic Dubost Blog: http://www.ludovic.org/blog/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost AIM: nvludo Yahoo: ludovic
participants (3)
-
Ludovic Dubost -
Sergiu Dumitriu -
Vincent Massol