Web-Developer's Project Template Directory

Question

IMPORTANT: The accepted answer was accepted post-bounty, not necessarily because I felt it was the best answer.

---

I find myself doing things over an

Answer 1

My web development framework sits in a git repository. Common code, such as general purpose PHP classes gets developed in the master branch. All work for a particular website gets done on a branch, and then changes that will help in future work get merged back into master.

This approach works well for me because I have full revision control of all the websites, and if I happen to fix a bug or implement a new feature while working on a branch I can do the merge, and then everything benefits.

Here's what my template looks like:

/
|-.htaccess            //mod_rewrite skeleton
|-admin/               //custom admin frontend to the CMS
|-classes/             //common PHP classes
|-dwoo/                //template system
|-config/              //configuration files (database, etc)
|-controllers/         //PHP scripts that handle particular URLs
|-javascript/
      |-tinyMCE/
      |-jquery/
|-modules              //these are modules for our custom CMS
      |-news/
      |-mailing_list/
      |-others
|-private/             //this contains files that won't be uploaded (.fla, .psd, etc)
      |-.htaccess      //just in case it gets uploaded, deny all
|-templates/           //template source files for dwoo

Answer 2

A very MS skewed view, but my SOP right now is along the lines of:

• documentation/
  • architecture/ (what you might call code documentation)
  • communications/ (important client docs)
  • spec/
  • whitepapers/
• graphics/
  • *.psd

• source/

  • com.mycompany.projectname.solutionA/
  • com.mycompany.projectname.solutionB/
  • com.mycompany.projectname.solutionC/

  • com.mycompany.projectname.solutionX/ (project in the business sense here)

    • businesslogic/
      • *.cs (or whatever)
    • (further projects - in the visual studio sense)

    • site/

      • handlers/ (rarely do I use actual .html these days)
      • modules/

      • resources/

        • img/ (pngs jpegs, gifs whatever)

          • skin/
            • icons/
            • backgrounds/

        • js/ (compressed when published)

          • library/ (standard code)
          • common/ (app specific code)
          • *.js (app specific code, hopefully nil)
        • css/
          • skinX/ (even if there is only "default")
            • extension.css
          • base.css
        • transforms/(always hidden from public by config or build process)
          • *.xslt
    • unittests/
      • mocks/
      • testmain.cs (or whatever)
• thirdparty/
  • dependencies

Answer 3

I think the structure is good. The addition of a few other folders depends on what type of work you are completing.

For freelancing and the like, the addition of PSD folders, client comments would be a nice addition.

Answer 4

At work we use Code Igniter as a PHP framework for our web applications and have created a new project template which does exactly that: Simple directory structure, Blueprint CSS, jQuery and the Code Igniter application folder, filled with a couple of commonly used libraries (Authentication, some speciales models for often used databases...).

The main motto here is: It's always easier to delete components than to add them. So fill your template up.

(And when I'm starting a new project in my spare time I sorely miss that template...)

Answer 5

I have been using the following setup for a while now with great results:

• /site: This is where my actual working website will live. I'll install my CMS or platform in this directory after the templates are created.
  • .htaccess (basic tweaks I usually find myself enabling anyway)
  • robots.txt (so I don't forget to disallow items like /admin later)

• /source: Contains any comps, notes, documents, specifications, etc.

• /templates: Start here! Create all static templates that will eventually need to be ported into the CMS or framework of /site.

  • /behavior
    • global.js (site-specific code; may be broken out into multiple files as needed)

  • /media: Images, downloadable files, etc. Organized as necessary

  • /style: I prefer modular CSS development so I normally end up with many stylesheet for each unique section of the website. This is cleaned up greatly with Blender - I highly recommend this tool!

    • behavior.css (any styling that requires a JS-enabled browser)
    • print.css (this eventually gets blended, so use @media print)
    • reset.css (Eric Meyer's)
    • screen.css (for @media screen, handheld)

  • /vendor: all 3rd party code (jQuery, shadowbox, etc.)

  • Blendfile.yaml (for Blender; see above)

  • template.html (basic starting template; can be copied and renamed for each unique template)

Answer 6

If you have a lot of projects with a lot of static content in common (e.g. jquery, css framework, etc) make yourself a media server to serve all these. Then, instead of creating a bunch of folder structure from a "template" all you do is include the right files in your project's html. If you really want a template, your template becomes one html file instead of a directory structure.

This also gives you an easy way to update the static media for your sites (e.g. moving to the next version of 960). you only have to do it in one place. Of course, you still have to make sure that your updates don't break existing sites! :)

You can make the scheme a bit more complicated if certain projects have overlapping needs but are different from others. Just have a directory at the top level of the server for each setup and to each setup corresponds one html "template". The main idea is to have to deal with only one copy of everything that is common.

You can certainly do this on a small VM (e.g. linode) for $20/mo or a virtual web-server on your current web server. You don't really need a server, for that matter, you just need a folder. However, I think you can have some significant performance gains by having a dedicated media servers. I'd recommend using a fine-tuned apache or nginx for this purpose.

As for site-specific static files, it is also a good idea that they live on the media server and the directory structure would probably be exactly what you have, but they would/should be empty directories.