views:

261

answers:

5

[This question is somewhat related to this question, but the answers are not...]

I have always used relative paths in HTML and scripting languages (PHP/ASP/JSP) to refer to EVERYTHING. I think the justification had to do with 'what if the website gets hosted in some weird subdirectory.' But my coworker has started throwing absolute paths into a PHP site we're working on. At first I was appalled, but then I thought, "why not? We'll never be hosted in a subdirectory." Nowadays, getting hosted in the root is not an uncommon necessity. Is it still necessary to "code" (markup, really) with relative paths? I think it's probably an antiquated practice by now.

+6  A: 

Definitely. You never know where your code is going to end up, or for what purpose.

Suppose you build a new version of a site, but to help your users transition, you move the old version to a "/classic" subdirectory. The same often happens the other way around where sites will host a beta version of the new redesign in a "/new" directory.

Building it properly the first time shouldn't be a hassle, and you'll thank yourself for it one day.

nickf
It's a hassle for included code, because we always have to deal with whether we're already IN a subdirectory or not. Maybe I should ask how to work around this PHP, next...
Yar
A "slight hassle," I meant. Thanks for your answer!
Yar
+2  A: 

Well, it's probably not the end of the world but it's building in a dependency that you don't need.

If for example you ever want to put a number of versions in subdirectories in a test harness, or subdirectories help to work around some other issue (such as combining this with some other app that insists on being in the root), you may find it harder.

Sure, you can probably always work around it in some other way - but the problem is you now have to.

frankodwyer
Nice answer, thank you.
Yar
+1  A: 

If you're using dynamically-generated pages, dynamically generate your URLs. For example, with JSTL use <c:url>. Not only does this allow you to move your pages in the future, it also ensures that your URLs will be properly escaped (tell the truth: how often do you build query strings with &amp;? if you want the W3C validator to accept them, you need to).

For my personal website, which uses PHP to build pages, I've created several methods: insertPageRef(), insertCodeRef(), and so on, that create valid HREFs. As a result, I don't hesitate to re-arrange my site structure as it evolves.

kdgregory
Excellent notes about your PHP methods... Thanks for your answer.
Yar
+1  A: 

The case of being moved to a subdirectory is fairly unusual, I'd say. Far more usual is being hosted on different servers: you create your site for testing on "dev.yourcompany.com" then go live by moving it to "www.yourcompany.com". In that case, you need to use relative links for obvious reasons.

AmbroseChapel
Right, by absolute I don't mean links that include the server name. That would be hard to test...
Yar
+1  A: 

Edit: Killed my opening paragraph as it was based on a miss-interpretation of the referenced article.

I always use an absolute path for the following reasons:

Includes: 1. When you use a templating system, you never know the directory structure that a document is going to have when it's calling the include. 2. If documents are going to be moved around, you can be pretty sure it's going to be the documents themselves rather than the includes. If it is the includes, then they're being moved my someone who knows what going on. Added to this, if it is someone not familiar with absolute/relative path, they'll understand absolute a lot better than relative.

css: (as well as the items above) 1. When editing with Web Developer, relative backgrounds disappear when your style sheet isn't in the same directory as the doc. 2. By spec, when you put something on the 'Net, it should be there for the duration. When I'm building something new, I build it in a new folder, or with a new file name and leave all the old docs alone.

Steve Perks
Thanks. That's no doubt what my coworker thinks, too.
Yar