On Tue, Mar 31, 2009 at 6:29 AM, Antonio Vidal Ferrer <antonio.vidal@xxxxxxxxxxxxxxxxxxxxx> wrote: > Hi, > > > > I need some advice in a simple topic. Which is better in performance and > usability for loading images and other content: > > > > This way: /images/January/myimage.jpg > > Or this way: ../../../myimage.jpg > > > > Thanks in advance for your advice > > > > Best, > > > > Toni Vidal. > Can't say for sure about performance, but I would assume that ../../.. is going to be significantly worse performance. As far as usability...whose usability? If this is just a img's src attribute in an HTML file, then the user doesn't care what the path is, they won't generally see it. From a developer point of view, I would say that this particular type of relative path is far less usable and will make your code non-portable. That may be a little counter intuitive because relative paths are generally preferred for portability, but the fact that you're going up one or more directories means the paths are not really a part of the code, they're external resources, so in order to keep it from breaking, you would need to move those along with the code that references them. One thing to keep in mind with portability in web applications is that once you've established a URL for something that faces the public, it's generally a good idea to always maintain that URL as at least one way of accessing that resource. So even if you decide to move the entire app and the external resources, you would probably want to use a rewrite rule or an alias to make the resources still available from the old location, in which case your absolute URL will still work. So long story short, I'd say avoiding the ../../../ notation for is probably best for all metrics. -Brian -- Feel free to contact me using PGP Encryption: Key Id: 0x3AA70848 Available from: http://pgp.mit.edu/ --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|