in reply to Design vs. Code vs. Maintenance

I'm working on a couple of sites with similar setups. What I've done is to commission an overall design for all of the pages. Then, I abstract out the parts that have to change for each (a navigation box, depending on where you are, a main graphic, the text of a separate page, and so forth). I break things down into templates on my own, and store those in a database.

I also store all of the page content in the database. Now there's also a web interface (with permissions and security checks) where various people can update the content.

Instead of building pages dynamically from the web server, I have a backend program, either run from cron nightly or activated automatically which walks through the hierarchy and updates any pages that have changed. I can afford to be a little bit inefficient with the substitution and transformation, because it doesn't happen in real time.

This seems to work pretty well for sites of only a couple of hundred pages, with only a few changes every day. Scalability isn't on my list of worries right now.

Replies are listed 'Best First'.
RE: Re: Design vs. Code vs. Maintenance
by BBQ (Curate) on May 17, 2000 at 21:14 UTC
    I've used that exact same setup in the past for larger websites (+500 pages), in combination with SSI for header/footer stuff. I'm not terribly worried about the sites that need constant work or are large projects where we have to allocate alot of programming man-hours, since those usually have small design update issues.

    The amount of effort put into changing 1 single script tends to be alot more than changing the entire site look and feel, and that's where we hit the hard cold bottom. Smaller sites shouldn't require a programmer's man-hour (which is more expensive than a HTMLers man-hour) when the maintenance is purely synthetic.

    I'm rambling... What I wanted to say is yeah, I like your setup and I've used it in the past, but I'm looking for a solution for the smaller, everyday sites (40 pages tops).