WebDeveloper.com �: Where Web Developers and Designers Learn How to Build Web Sites, Program in Java and JavaScript, and More!   
Web Developer Resource Directory WebDev Jobs
Animated GIFs
CSS
CSS Properties
Database
Design
Flash
HTML
HTML 4.01 Tags
JavaScript
.NET
PHP
Reference
Security
Site Management
Video
XML/RSS
WD Forums
 Client-Side
  Development

    HTML
    XML
    CSS
    Graphics
    JavaScript
    ASP
    Multimedia
    Web Video
    Accessibility
    Dreamweaver
    General
    Accessibility
    Dreamweaver
    Expression Web

    General

 Server-Side
  Development

    PHP
    Perl
    .NET
    Forum, Blog, Wiki & CMS
    SQL
    Java
    Others

 Site Management
    Domain Names
    Search Engines
    Website Reviews

 Web Development
  Business Issues

    Business Matters

 Etc.
    The Coffee Lounge
    Computer Issues
    Feedback




How to Set Up Your Web Site Hierarchy

by David Lawrence
Reprinted from Web Developer® magazine, Vol. 1 No.1 Winter 1996 © 1996

How one arranges one's Web site is an art as well as a science. It would be convenient to arrange your site all at one level, allowing for very short SRCs and HREFs. After a while, though, files start to pile up, and the one-level approach becomes unwieldy. I like to arrange my web site like a ranch with a toolshed: my HTML text files all at one level, and my auxiliary files in a hierarchical "kit" that is logically organized and at the same level as the text files. Here's an example:

The uppermost directory (seen as folders here on my Macintosh) is called "resources." From there, I break things down into images, movies, sounds, and software. Some of the directories have subdirectories, all allowing me to easily remember what path I want to take when browsing for an item or saving a finished piece to my hard drive or server. There's a further advantage: relative URLs. Because I can reference any item in my Web site with a direct, same-level call, or logical downstream call, I can transfer the whole Web site to a new server in one fell swoop, and all of the local links will remain intact. I've had to do this three times this year, and each time, I came to appreciate more and more this method of arranging my site's documents.

One other solution to the calendaring problem, where access to the cgi-bin directory is not available: tables in Netscape. Much faster to download than the image concatenation described in the main article (though not as visually diverse), tables are amazingly adept at some of the applications usually reserved for image maps.

I've taken the time to create a table for the calendar year 1996. It's very straightforward, loads rather quickly, and the code allows easy access to create links. If you like it, use it creatively, and send me the URL. Check it out at http://www.webdeveloper.com/cgi-perl/calendar.html.

One last tip: if the ISP you are currently using doesn't allow access to the cgi-bin, find out why. Maybe they just haven't thought about it, or maybe they don't know they can open up certain functions to their users and still maintain a level of security. Talk it over with the technical directors at your ISP. If they still won't come around, switch service providers to one that will. That's what I did.



HTML5 Development Center


Recent Articles