1.3 What is the philosophy behind Cheetah?

Cheetah's design was guided by these principles:

Python for the back end, Cheetah for the front end. Cheetah was designed to complement Python, not replace it.
Cheetah's core syntax should be easy for non-programmers to learn.
Cheetah should make code reuse easy by providing an object-oriented interface to templates that is accessible from Python code or other Cheetah templates.
Python objects, functions, and other data structures should be fully accessible in Cheetah.
Cheetah should provide flow control and error handling. Logic that belongs in the front end shouldn't be relegated to the back end simply because it's complex.
It should be easy to separate content, graphic design, and program code, but also easy to integrate them.
A clean separation makes it easier for a team of content writers, HTML/graphic designers, and programmers to work together without stepping on each other's toes and polluting each other's work. The HTML framework and the content it contains are two separate things, and analytical calculations (program code) is a third thing. Each team member should be able to concentrate on their specialty and to implement their changes without having to go through one of the others (i.e., the dreaded ``webmaster bottleneck'').
While it should be easy to develop content, graphics and program code separately, it should be easy to integrate them together into a website. In particular, it should be easy:
- for programmers to create reusable components and functions that are accessible and understandable to designers.
- for designers to mark out placeholders for content and dynamic components in their templates.
- for designers to soft-code aspects of their design that are either repeated in several places or are subject to change.
- for designers to reuse and extend existing templates and thus minimize duplication of effort and code.
- and, of course, for content writers to use the templates that designers have created.