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/intro.adp

This book is about designing and coding Content Management Systems from scratch. It covers revisioning, permissions, workflow, and templates, and by the time you've reached the end, you should be able to write your own enterprise-strength CMS from the ground up, or at least have a better appreciation of the issues involved.

If you're in need of a CMS, the first question is "Should I buy one or write my own?" There are many CMS products on the market, each offering different features, some filling specific niches and some claiming to be general enough to solve anyone's CM problem. But this doesn't guarantee you'll find a product that fits your needs, and it's not always the case that starting with an existing CMS and modifying it to fit your needs will be faster than writing your own.

The core of the problem is the choice facing software companies selling CMSes. It's impossible to write a product that will work out-of-the-box for most people -- there is no CMS equivalent of Microsoft Word. Each CMS vendor decides what type of CMS product they're going to write.

The first option is to target a specific market niche. For example, a software company could team with a law firm and try to build the world's finest document management system for lawyers. The market would be relatively small (at least small compared to the entire CM market), but the needs of each law firm would be similar enough to make possible a product that satisfies most law firms' needs with little or no customization. The goal would be great out-of-the-box functionality -- they install it from a CD and it just works.

The second option is the toolkit approach -- the product doesn't do much out-of-box, but with customization can be made to do almost anything. If you choose one of these products, you need to budget time and resources for the customization phase, often paying consultants from the vendor to explain how it really works. If there isn't a good match between your needs and the product's base features, or if your needs are complicated, the amount of programmer time needed for customization might be measured in man-years.

With either type of CMS product, the quality of fit is determined partially by your IT infrastructure. If you have standardized on, for example, Unix, Oracle, and Java, it makes sense to rule out all Windows-based CMSes.

If you choose a toolkit-style product, you should be sure the CMS is written in a language known by your programmers, or one that can be learned easily. If your staff does all its programming in C, you should restrict your choices to products that have full C interfaces.

If you have existing products that need to integrate with the CMS, you want to know the two products can coexist peacefully. For example, if you want your CMS and ecommerce product to share the same user information, but they use different databases, you have a problem.

Writing a custom CMS has a few advantages:

• You can choose the infrastructure. Most well-run tech departments will have standardized on one platform, one or two languages, one major database, and have a set of coding conventions and development practices that allows new members to be added to the team without being lost. Introducing a CMS product with its own language and database can be expensive as developers take time to get up to speed with the new tools.

• Integration issues are smaller. Coercing two products into working together can be a nightmare. Each product might have its own concept of users, roles, permissions, etc. What if you want your CMS to handle permission by using data from the company's intranet? With a custom CMS, this isn't a problem.

• You're not restricted by a vendor. If you write your own CMS, you're guaranteed of having the source code and able to make any modifications you need. If you have a closed-source product, you're limited by what the vendor gives you.

• A custom CMS will be simpler. A successful toolkit must be general enough to solve many types of CM problems. But going too far down this road leads to new problems -- as the product's designers think of more situations to be supported, the amount of code grows and the code base becomes more complicated. This is a problem because a CMS toolkit is a lot like a half-finished tool -- only after the customization phase does it do anything useful.

  If the code base is too complicated, the customization phase can be painfully slow. Perhaps the toolkit gives you a 30% head start, but getting to 40% takes months as your developers digest the code base, trying to figure out which parts can be ignored safely. Every line of code is in there for a reason -- to support someone's requirement -- but the extra functionality just gets in your way. In the end, you're left with the feeling that building the application that solved only your problem would have been faster than building on top of someone else's complicated, general-purpose app.

Writing your own CMS isn't always the right choice, but if you understand the issues involved and have a firm grasp of your requirements, it's easier than most people assume.

About the code

The code samples use Oracle and PHP. PHP was picked because it's simple, highly readable, and has good performance. One of its virtues is its small size; if you're an experienced developer, you can pick it up in an afternoon. It lacks the heavy-duty features of languages like Java, but since the application built in these chapters has its logic encapsulated in the database, PHP's role is small -- mostly passing values to and from the database, and generating some HTML. PHP is well-suited for this.

If there's a prerequisite for this book, it would be a strong understanding of relational databases. The heart of this application is in the database -- the tables define what the system is capable of doing, and the views and stored procedures contain the system's rules.

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/intro.adp