invalid command name "ns_adp_include"
while executing
"ns_adp_include header.adp "
invoked from within chunk: 2 of adp: /home/dvr/web/dvr/cmd/code-in-cms.adp
A content site is built with the labor of three groups: writers and editors generating content, graphics designers writing templates, and programmers writing code. The previous chapters focused on giving writers and editors the features they need.
At first glance, graphics designers and programmers have requirements similar to content creators -- both need version control systems for their files. This makes it tempting to expand the CMS to handle templates and source code, but there are a few reasons this is a bad idea.
Look at the situation facing a publishing team pre-CMS. Most pages on the site are static files maintained jointly by the programmer and designer. The programmer is happy because he's using the text-editor and version control system of his choice. The designer is happy using Dreamweaver and FTPing files into place. The person with the most reason to complain is the person with the least control: the content creator, who needs to go through the programmer or designer to get a change made. If changes are small and frequent, this process will also wear on the designer and programmer, who find themselves flooded with requests like "Can you fix the typo in the third paragraph on this page ..."
A CMS should fix the problems in this process without breaking what is already working. Everyone benefits by allowing the content creator from being able to update their own content, but there's little or no benefit in replacing tools that are already doing the job.
The best solution is a system that allows the programmer and designer to continue using the tools they like. If the CMS stores code and templates in the database or somewhere other than the file system, many of their favorite tools become difficult or impossible to use.
Most organizations with static-file sites have a procedure for moving content to the live site something like: (1) a content creator (usually with the help of the designer) puts a new page on the development machine; (2) an editor/manager reviews the page; (3) the production machine is updated by syncing its files with the files on the development machine. This last step usually requires only a few moments of a programmer's time, but it requires coordinating multiple people, which is something we want to avoid.
Since our CMS' revision and permission system allows content to be modified without the change being seen by the public, content creators can do all their work on the production machine/database. When an editor wants a story to go live, he clicks a link which makes a small change in the database, and the story goes live. The programmer's attention is no longer needed.
When a site is composed of static files, adding a page involves at least two changes: (1) adding the new page, and (2) updating the pages that should link to the new page. When it's time for the new page to be moved to production, it's common for the entire file tree to be copied to production to avoid the mistake of moving only part of the changes, which would result in either a page with no links to it, or a link to a page that doesn't exist.
With a CMS in place, most public pages can be generated on the fly by pulling content straight from the database. When a story goes live, the url for that story becomes available to the public and the page that lists all stories (in a department, for a writer, etc) is updated automatically. Editors can make changes without fear of creating dead links or orphaned pages. A change that required modifications to several pages before now takes only one click.
Content creators can preview content before it goes live. If something is wrong (the html is malformed, etc.), he'll see it and be able to fix it before making it go live. A programmer has no similar way of testing -- he can only change the code and see what parts of the site break. His changes should be made first on the development machine.
Writers will have multiple revisions of their stories; programmers will have multiple revisions of their files. A key difference is that programmers need to test all the files together, a writer doesn't. Changes to one story won't break another story, but small changes in one of the programmer's files can break code all over the site.
When changes are made to part of the code, the new site should be tested as a whole. When testing is completed, the entire code base should be moved to production at the same time.
Templates should be treated like code because they have more in common with code than content. Most templates will be used with many stories, so changes to a template require testing several pages before the developer can be confident nothing has been left broken. Also, changes to templates are often driven by changes in functionality brought on by new code. Testing is made easier by having code and templates stored in the same version control system, and moving from the development server to the production server in parallel.
A more sophisticated setup will use three servers: one production server, one development server, and one "staging" server. Programmers and graphics designers will make their changes on the development machine, but move the code to the staging server for testing. If the new code includes no data model or plsql changes, the staging server can be configured to talk to the production database, allowing the latest code to be tested with the latest content without fear of breaking the live site.
invalid command name "ns_adp_include"
while executing
"ns_adp_include footer.adp "
invoked from within chunk: 3 of adp: /home/dvr/web/dvr/cmd/code-in-cms.adp