Parent Path Debate

[wdmny]

I know that IIS 6 disables parent paths by default and I see in M@rco's blog that he "hates them with a vengence." The problem with not using them (at least with includes) though, is that your code files cannot be structured in a useful way, otherwise you will not be able to redistribute your code or to move your folders.

For instance, my programs usually consist of at least 100 ASP scripts. I organize them like so:

/program/
    admin/
    includes/
    users/

Now, I have global include files in the /includes/ folder and then files in the folders /admin/ and /users/ access these files using a "../includes/include.asp" type call. I cannot use a "/includes/include.asp" call because there are quite a few calls and generally when someone else installs the program, they will not be installing it in the default location.

This is not really a problem, as I think parent paths are a good solution (at least with includes). My debate is, why don't you like them and how do you propose the files be arranged?

[moospot]

In my case, I work for only one company and I am the only programmer/webmaster/whatever, so I use a system similar to what you have in place. I can see why it would be an issue for portability, but I agree with the point that it makes the file management much easier. The only other thing that I do is arrange certain files by using a prefix i.e. include files are prefixed with i_ (i_header.asp, i_footer.asp, etc). This may be a solution to the parent paths problem.

[wdmny]

The only other thing that I do is arrange certain files by using a prefix i.e. include files are prefixed with i_ (i_header.asp, i_footer.asp, etc). This may be a solution to the parent paths problem.

This would still require odd structuring because global includes would have to be placed in every sub folder. Instead of being able to place global configs in a single file under /includes/ the configs would have to be in three different places.

I would like to see what some of the anti parent path people think.

[MarcusJT]

I would like to see what some of the anti parent path people think.

Is that a hint?!

Clearly in situations where you need to be able to place a set of scripts at any place or level in a web site's folder structure and have them work straight off, using webroot-relative paths is a no-no. In such situations then the only clean solution *is* to use relative links as you suggest.

Of course, as we (should) all know, you can't dynamically include scripts, and although you can Server.Execute or Server.Transfer to them, they then execute within their own scope, which makes their use severely limited.

That said I have come up with one sneaky way to (sort of) get round this problem, but it only applies if the app will *always* be installed in a subfolder of the webroot (i.e. a direct descendant) AND the user wants to change the name of this subfolder (e.g. from "/wesblog/" to "/blog/").

What the user should do is install the scripts into the normal /wesblog/ folder, create a virtual folder called "/blog/" which points to the "/wesblog/" folder, then finally remove world-readable permissions to the "/wesblog/" folder from within the IIS snap-in. Then the app will only be available as "http://servername/blog", but the scripts themselves will still be able to use the root-relative paths to include other scripts within the "/wesblog/" subfolder hierarchy.

Please note that this only solves the server-side problem... root-relative links that will be parsed by the browser (i.e. IMG SRC attributes, A HREFs, etc.) will be broken, because they will attempt to access the folder which is no longer world-readable, instead of the virtual folder. However, since the links in the HTML *can* be constructed dynamically, this could be fixed by using a global/application variable to prefix each path with the location of the virtual folder, like so:

<img src="<% = WesBlogVirtualPath %>icon.jpg">

where WesBlogVirtualPath is elsewhere set equal to "/blog/", to continue with the example that I have used throughout this post.

It's not a very satisfactory approach, but it is an alternative one. However, I think in such a situation, using relative paths would be acceptable.

And with that, I'm off to bed! ZZZZzzzz....

[Thing]

I use a similar system to you Wes on my personal sites. However at work we have a HUGE e-commerce site so it doesn't work well in that type of environment. I have each section of the site in a different directory, and inside that directory I have their own individual includes. Even if it is an exact copy of my original include I place it in the subfolder. Sometimes it makes for a little more work, but it saves me more headaches than it creates.

[wdmny]

Is that a hint?!

Actually I was wondering what your opinion was since you usually back it up with some good thoughts, as you have here. I do use the same idea as your dynamic path for images in another situation that would otherwise require relative paths (user uploaded images in other folders).