www Needed in URL?

On the other hand, you can have a complete, working copy of your website on a local computer without changing the links. Some of the sites I maintain are mirrored, so all the links are local to the site. That way, I simply FTP any new or changed pages to the individual servers, but only after testing them on a local PC. The only visible difference between the mirrored & main site is the domain name, and E-mail address for each version. When a site reaches hundreds of pages, it makes life easier.

Some friends of mine had to move their website, after the current host had a server crash. The host's newest backup was bad, and what they restored was parts of four older versions. They didn't keep a copy on their hard drive, 'to save space', so the entire site was lost. If they had kept it the way I told them, it would have taken 15 minutes to move to the new host & servers.

The reason to avoid hard coding numerical constants isn't so that you only have to change one thing -- we have computers that can change many things in an eyblink -- but rather to give them names that make sense (Using DaysPerWeek rather than 7, for example, is a lot easier to follow [and the number of days in a week are not likely to change!]) and thus make the code more readable. That doesn't apply to URLs. the other reason is to differentiate a 7 that is the number of days in a week in one place from a 7 that is a manager's IQ in another place. That also doesn't apply to URLs.

Also, if you move that file and alsways use complete URLs, the URL is a unique string that points to that file and no other, making a global search and replace across multiple files simple to do.

Content-Transfer-Encoding: 8Bit

Michael A. Terrell wrote:

Slightly easier, but not much. Global search and replace in all files in a directory including subdirectories handles the case of having a local copy just fine.

That's a backup issue, not a partial vs. complete URL issue.

Maybe I was thinking of the pathological case (imagine your surprise! ;-) where you move one file, then have to modify half-a-dozen other files to point to its new home. That way, you only have one thing per file to change, like or something like that.

But, I must admit, I've been working on my client's website, and I have a WHOLE BUNCH of hard-coded URLs that point to stuff that doesn't change, notably, the example.net/images directory, so I guess I'm guilty of doing what I just said you shouldn't do. But the _target_ doesn't move, just the file that's referring to them.

That's different! [1] Never Mind.

Cheers! Rich

True, but I also only have one thing to change -- all instances of

I have been trying to think of a realy pathological case where it takes more than an extra second or so to change all the full URLs. I can't think of one.

I can think of one really good reason NOT to use relative paths:

ASP.NET won't touch an HTML tag, such as , or . If you place a master page (the dot-net equivalent of a cascading style sheet) in a different directory from the content page, you can end up with busted links that dot-NET can't catch at design-time. You could mark the URL relative to the content page, but that just limits where you can place the master page, so same difference.

You could turn the tags into server-side controls, in which case ASP can detect and correct the errors. But that seems awfully complicated to me, and not worth the effort.

I would just do a global search & replace.

-mpm

The pathological cases i have seen come refactoring code where you need selective (by file) global replaces. Often for interim states.

On Thu, 31 Jul 2008 22:53:51 +0000, Guy Macon wrote: ...

When you do it by hand. ;-)

Cheers! Rich

Jeff Liebermann:

No need to dig!