Add the webpage sources

17 files changed, 970 insertions, 0 deletions

diff --git a/sources/Makefile b/sources/Makefile
new file mode 100644
index 0000000..f390dee
--- /dev/null
+++ b/sources/Makefile
@@ -0,0 +1,88 @@
+# Makefile for Sphinx documentation
+#
+
+# You can set these variables from the command line.
+SPHINXOPTS    =
+SPHINXBUILD   = sphinx-build
+PAPER         =
+
+# Internal variables.
+PAPEROPT_a4     = -D latex_paper_size=a4
+PAPEROPT_letter = -D latex_paper_size=letter
+ALLSPHINXOPTS   = -d _build/doctrees $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) .
+
+.PHONY: help clean html dirhtml pickle json htmlhelp qthelp latex changes linkcheck doctest
+
+help:
+	@echo "Please use \`make <target>' where <target> is one of"
+	@echo "  html      to make standalone HTML files"
+	@echo "  dirhtml   to make HTML files named index.html in directories"
+	@echo "  pickle    to make pickle files"
+	@echo "  json      to make JSON files"
+	@echo "  htmlhelp  to make HTML files and a HTML help project"
+	@echo "  qthelp    to make HTML files and a qthelp project"
+	@echo "  latex     to make LaTeX files, you can set PAPER=a4 or PAPER=letter"
+	@echo "  changes   to make an overview of all changed/added/deprecated items"
+	@echo "  linkcheck to check all external links for integrity"
+	@echo "  doctest   to run all doctests embedded in the documentation (if enabled)"
+
+clean:
+	-rm -rf _build/*
+
+html:
+	$(SPHINXBUILD) -b html $(ALLSPHINXOPTS) _build/html
+	@echo
+	@echo "Build finished. The HTML pages are in _build/html."
+
+dirhtml:
+	$(SPHINXBUILD) -b dirhtml $(ALLSPHINXOPTS) _build/dirhtml
+	@echo
+	@echo "Build finished. The HTML pages are in _build/dirhtml."
+
+pickle:
+	$(SPHINXBUILD) -b pickle $(ALLSPHINXOPTS) _build/pickle
+	@echo
+	@echo "Build finished; now you can process the pickle files."
+
+json:
+	$(SPHINXBUILD) -b json $(ALLSPHINXOPTS) _build/json
+	@echo
+	@echo "Build finished; now you can process the JSON files."
+
+htmlhelp:
+	$(SPHINXBUILD) -b htmlhelp $(ALLSPHINXOPTS) _build/htmlhelp
+	@echo
+	@echo "Build finished; now you can run HTML Help Workshop with the" \
+	      ".hhp project file in _build/htmlhelp."
+
+qthelp:
+	$(SPHINXBUILD) -b qthelp $(ALLSPHINXOPTS) _build/qthelp
+	@echo
+	@echo "Build finished; now you can run "qcollectiongenerator" with the" \
+	      ".qhcp project file in _build/qthelp, like this:"
+	@echo "# qcollectiongenerator _build/qthelp/Cheetah Template Engine.qhcp"
+	@echo "To view the help file:"
+	@echo "# assistant -collectionFile _build/qthelp/Cheetah Template Engine.qhc"
+
+latex:
+	$(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) _build/latex
+	@echo
+	@echo "Build finished; the LaTeX files are in _build/latex."
+	@echo "Run \`make all-pdf' or \`make all-ps' in that directory to" \
+	      "run these through (pdf)latex."
+
+changes:
+	$(SPHINXBUILD) -b changes $(ALLSPHINXOPTS) _build/changes
+	@echo
+	@echo "The overview file is in _build/changes."
+
+linkcheck:
+	$(SPHINXBUILD) -b linkcheck $(ALLSPHINXOPTS) _build/linkcheck
+	@echo
+	@echo "Link check complete; look for any errors in the above output " \
+	      "or in _build/linkcheck/output.txt."
+
+doctest:
+	$(SPHINXBUILD) -b doctest $(ALLSPHINXOPTS) _build/doctest
+	@echo "Testing of doctests in the sources finished, look at the " \
+	      "results in _build/doctest/output.txt."
diff --git a/sources/cheetahui/theme.conf b/sources/cheetahui/theme.conf
new file mode 100644
index 0000000..cc66429
--- /dev/null
+++ b/sources/cheetahui/theme.conf
@@ -0,0 +1,4 @@
+[theme]
+inherit = basic
+stylesheet = cheetahui.css
+
diff --git a/sources/chep.rst b/sources/chep.rst
new file mode 100644
index 0000000..ece151a
--- /dev/null
+++ b/sources/chep.rst
@@ -0,0 +1,17 @@
+Cheetah Enhancement Proposals
+=============================
+
+The concept of the **Cheetah Enhancement Proposal** is similar to the 
+`Python Enhancement Proposal <http://www.python.org/dev/peps/>`_ in that 
+they are used to outline the future development of Cheetah as both a 
+language and a framework.
+
+Existing CHEPs
+--------------
+
+.. toctree::
+   :maxdepth: 1 
+    
+   cheps/1_chep.rst
+   cheps/2_import.rst
+   cheps/3_super.rst
diff --git a/sources/cheps/1_chep.rst b/sources/cheps/1_chep.rst
new file mode 100644
index 0000000..65c54a2
--- /dev/null
+++ b/sources/cheps/1_chep.rst
@@ -0,0 +1,26 @@
+(#1) CHEP Purpose and Guidelines
+=================================
+
+
+:CHEP: 1
+:Title: CHEP Purpose and Guidelines
+:Version: 1
+:Author: R Tyler Ballance <tyler at slide.com>
+:Status: Active
+:Type: Process
+:Content-Type: text/x-rst
+:Created: 07-Jun-2009
+
+----
+
+Abstract
+--------
+One can consider the basis for all CHEP documents to be 
+modeled after `PEP #1 <http://www.python.org/dev/peps/pep-0001/>`_, 
+for this reason you should refer to `PEP #1 <http://www.python.org/dev/peps/pep-0001/>`_
+for the true CHEP "purpose and guidelines" instead of them being 
+enumerated here (and duplicated).
+
+Copyright
+---------
+This document has been placed in the public domain.
diff --git a/sources/cheps/2_import.rst b/sources/cheps/2_import.rst
new file mode 100644
index 0000000..8f3a837
--- /dev/null
+++ b/sources/cheps/2_import.rst
@@ -0,0 +1,122 @@
+(#2) Conditionalized #import behavior
+=====================================
+
+
+:CHEP: 2
+:Title: Conditionalized #import behavior
+:Version: 1
+:Author: R Tyler Ballance <tyler at slide.com>
+:Status: Draft
+:Type: Standards Track
+:Content-Type: text/x-rst
+:Created: 07-Jun-2009
+
+----
+
+Abstract
+--------
+This CHEP proposes an update to the way the #import and #from 
+directives are handled such that locally scoped imports and 
+module-level imports are handled appropriately.
+
+
+Motivation
+----------
+Currently Cheetah (v2.2.1) provides two different, but mutually exclusive, 
+means of importing Python modules with the #from/#import directives. The 
+"traditional" handling for #from/#import (hereafter referred to as "module imports")
+is that the generated import statements shall all be relocated to 
+the top of the generated module's source code, i.e. ::
+
+    #import cjson
+
+    Hello $cjson.encode([1, 2, 3])
+    
+
+Will result in generated module code along the lines of::
+
+    import cjson
+
+    class Foo(Template):
+        def writeBody(self):
+            write('Hello ')
+            write(cjson.encode([1, 2, 3]))
+
+
+Also currently in Cheetah is the ability to switch off this 
+behavior and enable location specific #from/#import handling
+(hereafter referred to as "function imports") in the generated 
+code, with this block of Cheetah for example::
+
+    #def aFunction(arg)
+        #try
+            #from hashlib import md5
+        #except ImportError
+            #from md5 import md5
+        #end try
+        #return $md5.new(arg).hexdigest()
+    #end def
+
+Will result in code generated with everything in
+place such that the Python looks something like::
+
+    class Foo(Template):
+        def aFunction(self, arg):
+            try:
+                from hashlib import md5
+            except ImportError:
+                from md5 import md5
+            return md5.new(arg).hexdigest()
+
+
+These two approaches to handling the #from/#import directives
+are both beneficial for different situations but currently they
+are handled in mutually exclusive code paths and in mutually 
+exclusive fashions. 
+
+Specification
+-------------
+The change in #from/#import behavior and how these directives 
+are handled is all based on context of their use, making the 
+#from/#import handling "intelligent". For module imports, the
+"traditional" handling of the #from/#import directives will
+still apply. Whereas function imports will result in inline 
+generated import code.
+
+The basic premise of the change proposed by this document is 
+that all #from/#import directives contained within a #def/#end def
+closure will result in import statements contained within that 
+function block whereas everywhere else the statements will be relocated
+to the top of the generated module code (i.e. the module import)
+
+
+Rationale
+---------
+The concept of the "function import" was introduced in Cheetah v2.1.0
+and quickly retrofitted to "live" behind a compiler setting due to the 
+regressions with older templates or templates that were designed to utilize
+module imports (through heavy #block/#end block use, etc). Through discussion
+with Tavis Rudd, this middle ground between the two styles of importing was 
+concluded to be the most reasonable solution to providing "pythonic" import
+functionality (i.e. "function import" also known as "inline imports") while 
+still providing the ability to have #from/#import directives declared at the 
+module scope within the template (within the Cheetah templates, markup and most
+directives declared within the module scope are placed inside the default method).
+
+
+Backwards Compatibility
+-----------------------
+Changes proposed in this document should be *mostly* backwards 
+compatible with current versions of Cheetah, Any unforeseen issues 
+could arise from the use of #from/#import inside of a function 
+expecting those symbols to be available outside of the function
+that they're declared in.
+
+
+Reference Implementation
+------------------------
+*still in development*
+
+Copyright
+---------
+This document has been placed in the public domain.
diff --git a/sources/cheps/3_super.rst b/sources/cheps/3_super.rst
new file mode 100644
index 0000000..0c04784
--- /dev/null
+++ b/sources/cheps/3_super.rst
@@ -0,0 +1,36 @@
+(#3) Exposing of super() and self via Template searchList 
+=========================================================
+
+
+:CHEP: 3
+:Title: Exposing of super() and self via Template searchList 
+:Version: 1
+:Author: R Tyler Ballance <tyler at slide.com>
+:Status: Draft
+:Type: Standards Track
+:Content-Type: text/x-rst
+:Created: 07-Jun-2009
+
+----
+
+Abstract
+--------
+
+Specification
+-------------
+
+Motivation
+----------
+
+Rationale
+---------
+
+Backwards Compatibility
+-----------------------
+
+Reference Implementation
+------------------------
+
+Copyright
+---------
+This document has been placed in the public domain.
diff --git a/sources/conf.py b/sources/conf.py
new file mode 100644
index 0000000..9a55e8f
--- /dev/null
+++ b/sources/conf.py
@@ -0,0 +1,197 @@
+# -*- coding: utf-8 -*-
+#
+# Cheetah Template Engine documentation build configuration file, created by
+# sphinx-quickstart on Sun May 31 22:23:43 2009.
+#
+# This file is execfile()d with the current directory set to its containing dir.
+#
+# Note that not all possible configuration values are present in this
+# autogenerated file.
+#
+# All configuration values have a default; values that are commented out
+# serve to show the default.
+
+import sys, os
+
+# If extensions (or modules to document with autodoc) are in another directory,
+# add these directories to sys.path here. If the directory is relative to the
+# documentation root, use os.path.abspath to make it absolute, like shown here.
+#sys.path.append(os.path.abspath('.'))
+
+# -- General configuration -----------------------------------------------------
+
+# Add any Sphinx extension module names here, as strings. They can be extensions
+# coming with Sphinx (named 'sphinx.ext.*') or your custom ones.
+extensions = [
+    'sphinx.ext.autodoc',
+    'github.tools.sphinx',
+    ]
+
+# Add any paths that contain templates here, relative to this directory.
+templates_path = ['_templates']
+
+# The suffix of source filenames.
+source_suffix = '.rst'
+
+# The encoding of source files.
+#source_encoding = 'utf-8'
+
+# The master toctree document.
+master_doc = 'index'
+
+# General information about the project.
+project = u'Cheetah'
+copyright = u'2009, R. Tyler Ballance'
+
+# The version info for the project you're documenting, acts as replacement for
+# |version| and |release|, also used in various other places throughout the
+# built documents.
+#
+# The short X.Y version.
+version = '2.2.1'
+# The full version, including alpha/beta/rc tags.
+release = '2.2.1'
+
+# The language for content autogenerated by Sphinx. Refer to documentation
+# for a list of supported languages.
+#language = None
+
+# There are two options for replacing |today|: either, you set today to some
+# non-false value, then it is used:
+#today = ''
+# Else, today_fmt is used as the format for a strftime call.
+#today_fmt = '%B %d, %Y'
+
+# List of documents that shouldn't be included in the build.
+#unused_docs = []
+
+# List of directories, relative to source directory, that shouldn't be searched
+# for source files.
+exclude_trees = ['_build']
+
+# The reST default role (used for this markup: `text`) to use for all documents.
+#default_role = None
+
+# If true, '()' will be appended to :func: etc. cross-reference text.
+add_function_parentheses = True
+
+# If true, the current module name will be prepended to all description
+# unit titles (such as .. function::).
+add_module_names = True
+
+# If true, sectionauthor and moduleauthor directives will be shown in the
+# output. They are ignored by default.
+#show_authors = False
+
+# The name of the Pygments (syntax highlighting) style to use.
+pygments_style = 'sphinx'
+
+# A list of ignored prefixes for module index sorting.
+#modindex_common_prefix = []
+
+
+# -- Options for HTML output ---------------------------------------------------
+
+# The theme to use for HTML and HTML Help pages.  Major themes that come with
+# Sphinx are currently 'default' and 'sphinxdoc'.
+html_theme = 'sphinxdoc'
+
+# Theme options are theme-specific and customize the look and feel of a theme
+# further.  For a list of options available for each theme, see the
+# documentation.
+#html_theme_options = {}
+
+# Add any paths that contain custom themes here, relative to this directory.
+html_theme_path = ['.']
+
+# The name for this set of Sphinx documents.  If None, it defaults to
+# "<project> v<release> documentation".
+html_title = u'Cheetah - The Python-Powered Template Engine'
+
+# A shorter title for the navigation bar.  Default is the same as html_title.
+#html_short_title = None
+
+# The name of an image file (relative to this directory) to place at the top
+# of the sidebar.
+#html_logo = None
+
+# The name of an image file (within the static path) to use as favicon of the
+# docs.  This file should be a Windows icon file (.ico) being 16x16 or 32x32
+# pixels large.
+#html_favicon = None
+
+# Add any paths that contain custom static files (such as style sheets) here,
+# relative to this directory. They are copied after the builtin static files,
+# so a file named "default.css" will overwrite the builtin "default.css".
+html_static_path = ['_static']
+
+# If not '', a 'Last updated on:' timestamp is inserted at every page bottom,
+# using the given strftime format.
+html_last_updated_fmt = '%b %d, %Y'
+
+# If true, SmartyPants will be used to convert quotes and dashes to
+# typographically correct entities.
+html_use_smartypants = True
+
+# Custom sidebar templates, maps document names to template names.
+#html_sidebars = {}
+
+# Additional templates that should be rendered to pages, maps page names to
+# template names.
+#html_additional_pages = {}
+
+# If false, no module index is generated.
+html_use_modindex = True
+
+# If false, no index is generated.
+html_use_index = True
+
+# If true, the index is split into individual pages for each letter.
+#html_split_index = False
+
+# If true, links to the reST sources are added to the pages.
+html_show_sourcelink = True
+
+# If true, an OpenSearch description file will be output, and all pages will
+# contain a <link> tag referring to it.  The value of this option must be the
+# base URL from which the finished HTML is served.
+#html_use_opensearch = ''
+
+# If nonempty, this is the file name suffix for HTML files (e.g. ".xhtml").
+#html_file_suffix = ''
+
+# Output file base name for HTML help builder.
+htmlhelp_basename = 'CheetahTemplateEnginedoc'
+
+
+# -- Options for LaTeX output --------------------------------------------------
+
+# The paper size ('letter' or 'a4').
+#latex_paper_size = 'letter'
+
+# The font size ('10pt', '11pt' or '12pt').
+#latex_font_size = '10pt'
+
+# Grouping the document tree into LaTeX files. List of tuples
+# (source start file, target name, title, author, documentclass [howto/manual]).
+latex_documents = [
+  ('index', 'CheetahTemplateEngine.tex', u'Cheetah Template Engine Documentation',
+   u'R. Tyler Ballance', 'manual'),
+]
+
+# The name of an image file (relative to this directory) to place at the top of
+# the title page.
+#latex_logo = None
+
+# For "manual" documents, if this is true, then toplevel headings are parts,
+# not chapters.
+#latex_use_parts = False
+
+# Additional stuff for the LaTeX preamble.
+#latex_preamble = ''
+
+# Documents to append as an appendix to all manuals.
+#latex_appendices = []
+
+# If false, no module index is generated.
+#latex_use_modindex = True
diff --git a/sources/developers.rst b/sources/developers.rst
new file mode 100644
index 0000000..8d9516e
--- /dev/null
+++ b/sources/developers.rst
@@ -0,0 +1,49 @@
+Contributing to Cheetah
+=======================
+
+Cheetah is the work of many volunteers. If you use Cheetah, share your experiences, 
+tricks, customizations, and frustrations. Please join the `mailing list <http://lists.sourceforge.net/lists/listinfo/cheetahtemplate-discuss>`_
+
+
+Getting the Code
+----------------
+The Cheetah source code is stored in a central **Git** repository
+hosted primarily by `GitHub <http://github.com>`_. The primary Git 
+repository can be found `here <http://github.com/cheetahtemplate/cheetah>`_.
+
+
+Development Process
+-------------------
+The typical development workflow for Cheetah revolves around 
+two primary branches **maint** and **next**. The **next** branch is where development 
+planned for the next release of Cheetah is. The **maint** branch 
+on the otherhand is where backported fixes and patches will be applied for 
+the current release of Cheetah will go, it's common for a patch 
+to be applied to maint and next at the same time.
+
+Anyone and everyone is encouraged to submit patches at any time, but as far 
+as bugs or feature requests go, we try to file those *first* in the `Cheetah Bug Tracker <http://bugs.cheetahtemplate.org>`_
+and then they can be organized into particular releases as is necessary.
+
+In addition to the bug tracker, Cheetah uses `Hudson <http://hudson-ci.org>`_ for 
+automating builds and test runs on a number of platforms (see: `Cheetah's Hudson <http://hudson.cheetahtemplate.org>`_).
+Prior to the tarballing of
+a release, **all** tests must be passing before the **next** branch is merged down
+to the Git **master** branch where the release tarball will actually be created from.
+
+
+Filing Bugs
+-----------
+No software is perfect, and unfortunately no bug report is either. If you've 
+found yourself faced with a bug in Cheetah, or just have a good idea for a 
+new feature, we kindly ask that you create an issue in the `Cheetah Bug Tracker <http://bugs.cheetahtemplate.org>`_.
+
+Some tips for filing a *useful* bug report, try to include the following:
+
+* A description of what you were trying to do, and what happened (i.e. reproduction steps), the more code you can include the better.
+* Any and all tracebacks or compiler errors
+* The version of Cheetah you're using
+* The version of Python you're using
+* The operating system you're running Cheetah on
+* Any other pieces of information you might think are relevant
+
diff --git a/sources/documentation.rst b/sources/documentation.rst
new file mode 100644
index 0000000..fd7c086
--- /dev/null
+++ b/sources/documentation.rst
@@ -0,0 +1,12 @@
+User Documentation
+==================
+
+Simple Recipes
+--------------
+.. toctree::
+   :maxdepth: 2
+
+   recipes/inheritance.rst
+   recipes/precompiled.rst
+   recipes/staticmethod.rst
+   recipes/writing_a_recipe.rst
diff --git a/sources/download.rst b/sources/download.rst
new file mode 100644
index 0000000..36009c1
--- /dev/null
+++ b/sources/download.rst
@@ -0,0 +1,19 @@
+Downloading Cheetah
+===================
+
+The most recent stable release of Cheetah **v2.2.1** which was released on
+June 1st, 2009.
+
+Download v2.2.1
+^^^^^^^^^^^^^^^
+* `v2.2.1 tarball <http://github.com/cheetahtemplate/cheetah/tarball/v2.2.1>`_
+* `v2.2.1 zip <http://github.com/cheetahtemplate/cheetah/zipball/v2.2.1>`_
+
+You can keep up to date with release candidates or other downloads of Cheetah by 
+visiting the `cheetahtemplate GitHub page <http://github.com/cheetahtemplate/cheetah/downloads>`_
+
+**Note to Windows users:** You should install the compiled version of Cheetah's 
+NameMapper. It is dramatically faster than the pure Python version, in the source
+tree you can find compiled versions for Python 2.4: namemapper.pyd2.4, 
+Python 2.5: namemapper.pyd2.5. Install it wherever your system puts 
+Cheetah/NameMapper.py. Strip the version numbers off the filename.
diff --git a/sources/index.rst b/sources/index.rst
new file mode 100644
index 0000000..fe3fa98
--- /dev/null
+++ b/sources/index.rst
@@ -0,0 +1,82 @@
+.. Cheetah Template Engine documentation master file, created by
+   sphinx-quickstart on Sun May 31 22:23:43 2009.
+   You can adapt this file completely to your liking, but it should at least
+   contain the root `toctree` directive.
+
+Cheetah, the Python-Powered Template Engine
+===========================================
+
+Introduction
+------------
+Cheetah is an `open source <https://github.com/rtyler/cheetah/tree>`_ template
+engine and code-generation tool written in `Python <http://python.org>`_. Cheetah
+can be used unto itself, or incorporated with other technologies and stacks regardless
+of whether they're written in Python or not. 
+
+At its core, Cheetah is a domain-specific language for markup generation and 
+templating which allows for full integration with existing Python code but also 
+offers extensions to traditional Python syntax to allow for easier text-generation.
+
+Talk Cheetah
+^^^^^^^^^^^^
+You can get involved and talk with Cheetah developers on the `Cheetah mailing list <http://lists.sourceforge.net/lists/listinfo/cheetahtemplate-discuss>`_
+(*cheetahtemplate-discuss@lists.sourceforge.net*) or on the **IRC** channel: 
+**#cheetah** on `Freenode <http://freenode.net/>`_
+
+Contents
+^^^^^^^^^
+
+.. toctree::
+   :maxdepth: 1
+
+   developers.rst
+   download.rst
+   roadmap.rst
+   documentation.rst
+   chep.rst
+
+
+Cheetah in a nutshell
+---------------------
+Below is a simple example of some Cheetah code, as you can see it's practically
+Python. You can import, inherit and define methods just like in a regular Python 
+module, since that's what your Cheetah templates are compiled to :) ::
+
+    #from Cheetah.Template import Template
+    #extends Template
+
+    #set $people = [{'name' : 'Tom', 'mood' : 'Happy'}, {'name' : 'Dick', 
+                            'mood' : 'Sad'}, {'name' : 'Harry', 'mood' : 'Hairy'}]
+
+    <strong>How are you feeling?</strong>
+    <ul>
+        #for $person in $people
+            <li>
+                $person['name'] is $person['mood']
+            </li>
+        #end for
+    </ul>
+
+
+Why Cheetah?
+------------
+
+* Cheetah is supported by every major Python web framework.
+* It is fully documented and is supported by an active user community.
+* It can output/generate any text-based format.
+* Cheetah compiles templates into optimized, yet readable, Python code.
+* It blends the power and flexibility of Python with a simple template language that non-programmers can understand. 
+* It gives template authors full access to any Python data structure, module, function, object, or method in their templates. Meanwhile, it provides a way for administrators to selectively restrict access to Python when needed. 
+* Cheetah makes code reuse easy by providing an object-oriented interface to templates that is accessible from Python code or other Cheetah templates. One template can subclass another and selectively reimplement sections of it. Cheetah templates can be subclasses of any Python class and vice-versa. 
+* It provides a simple, yet powerful, caching mechanism that can dramatically improve the performance of a dynamic website. 
+* It encourages clean separation of content, graphic design, and program code. This leads to highly modular, flexible, and reusable site architectures, shorter development time, and HTML and program code that is easier to understand and maintain. It is particularly well suited for team efforts. 
+* Cheetah can be used to generate static html via its command-line tool.
+
+
+Indices and tables
+------------------
+
+* :ref:`genindex`
+* :ref:`modindex`
+* :ref:`search`
+
diff --git a/sources/make.bat b/sources/make.bat
new file mode 100644
index 0000000..b5c2e3e
--- /dev/null
+++ b/sources/make.bat
@@ -0,0 +1,112 @@
+@ECHO OFF
+
+REM Command file for Sphinx documentation
+
+set SPHINXBUILD=sphinx-build
+set ALLSPHINXOPTS=-d _build/doctrees %SPHINXOPTS% .
+if NOT "%PAPER%" == "" (
+	set ALLSPHINXOPTS=-D latex_paper_size=%PAPER% %ALLSPHINXOPTS%
+)
+
+if "%1" == "" goto help
+
+if "%1" == "help" (
+	:help
+	echo.Please use `make ^<target^>` where ^<target^> is one of
+	echo.  html      to make standalone HTML files
+	echo.  dirhtml   to make HTML files named index.html in directories
+	echo.  pickle    to make pickle files
+	echo.  json      to make JSON files
+	echo.  htmlhelp  to make HTML files and a HTML help project
+	echo.  qthelp    to make HTML files and a qthelp project
+	echo.  latex     to make LaTeX files, you can set PAPER=a4 or PAPER=letter
+	echo.  changes   to make an overview over all changed/added/deprecated items
+	echo.  linkcheck to check all external links for integrity
+	echo.  doctest   to run all doctests embedded in the documentation if enabled
+	goto end
+)
+
+if "%1" == "clean" (
+	for /d %%i in (_build\*) do rmdir /q /s %%i
+	del /q /s _build\*
+	goto end
+)
+
+if "%1" == "html" (
+	%SPHINXBUILD% -b html %ALLSPHINXOPTS% _build/html
+	echo.
+	echo.Build finished. The HTML pages are in _build/html.
+	goto end
+)
+
+if "%1" == "dirhtml" (
+	%SPHINXBUILD% -b dirhtml %ALLSPHINXOPTS% _build/dirhtml
+	echo.
+	echo.Build finished. The HTML pages are in _build/dirhtml.
+	goto end
+)
+
+if "%1" == "pickle" (
+	%SPHINXBUILD% -b pickle %ALLSPHINXOPTS% _build/pickle
+	echo.
+	echo.Build finished; now you can process the pickle files.
+	goto end
+)
+
+if "%1" == "json" (
+	%SPHINXBUILD% -b json %ALLSPHINXOPTS% _build/json
+	echo.
+	echo.Build finished; now you can process the JSON files.
+	goto end
+)
+
+if "%1" == "htmlhelp" (
+	%SPHINXBUILD% -b htmlhelp %ALLSPHINXOPTS% _build/htmlhelp
+	echo.
+	echo.Build finished; now you can run HTML Help Workshop with the ^
+.hhp project file in _build/htmlhelp.
+	goto end
+)
+
+if "%1" == "qthelp" (
+	%SPHINXBUILD% -b qthelp %ALLSPHINXOPTS% _build/qthelp
+	echo.
+	echo.Build finished; now you can run "qcollectiongenerator" with the ^
+.qhcp project file in _build/qthelp, like this:
+	echo.^> qcollectiongenerator _build\qthelp\Cheetah Template Engine.qhcp
+	echo.To view the help file:
+	echo.^> assistant -collectionFile _build\qthelp\Cheetah Template Engine.ghc
+	goto end
+)
+
+if "%1" == "latex" (
+	%SPHINXBUILD% -b latex %ALLSPHINXOPTS% _build/latex
+	echo.
+	echo.Build finished; the LaTeX files are in _build/latex.
+	goto end
+)
+
+if "%1" == "changes" (
+	%SPHINXBUILD% -b changes %ALLSPHINXOPTS% _build/changes
+	echo.
+	echo.The overview file is in _build/changes.
+	goto end
+)
+
+if "%1" == "linkcheck" (
+	%SPHINXBUILD% -b linkcheck %ALLSPHINXOPTS% _build/linkcheck
+	echo.
+	echo.Link check complete; look for any errors in the above output ^
+or in _build/linkcheck/output.txt.
+	goto end
+)
+
+if "%1" == "doctest" (
+	%SPHINXBUILD% -b doctest %ALLSPHINXOPTS% _build/doctest
+	echo.
+	echo.Testing of doctests in the sources finished, look at the ^
+results in _build/doctest/output.txt.
+	goto end
+)
+
+:end
diff --git a/sources/recipes/inheritance.rst b/sources/recipes/inheritance.rst
new file mode 100644
index 0000000..983e044
--- /dev/null
+++ b/sources/recipes/inheritance.rst
@@ -0,0 +1,62 @@
+Basic Inheritance
+=================
+
+Introduction
+------------
+Cheetah, like Python, is an object-oriented language if you so choose to 
+use it in that fashion. That is to say that you can use Cheetah in with 
+object-oriented principles *or* you can use Cheetah in a strictly functional
+sense, like Python, Cheetah does not place restrictions on these barriers.
+
+While Cheetah is not strictly Python, it was designed as such to interoperate,
+particularly with the notion of classes, with Python itself. In effect you can 
+define Python classes that inherit and extend from Cheetah-derived classes and 
+vice versa. For this, Cheetah defines a few **directives** (denoted with the `\#` 
+hash-mark) that are of some help, the most important one being the `\#extends`
+directive, with others playing important roles like `\#import`, `\#attr` and `\#super`
+
+In this recipe/tutorial I intend to explain and define a few key inheritance
+patterns with Cheetah, being:
+
+* A Cheetah Template inheriting from Python
+* Python inheriting from a Cheetah Template
+* Cheetah Templates and "*mixins*"
+
+This document also operates on the assumption that the reader is at least 
+somewhat familiar with the basic tenets of object-oriented programming in 
+Python.
+
+
+Cheetah inheriting from Python
+------------------------------
+Whether or not you are aware of it, Cheetah templates are always inheriting from 
+a Python class by default. Unless otherwise denoted, Cheetah templates are compiled 
+to Python classes that subclass from the `Cheetah.Template.Template` class.
+
+What if you would like to introduce your own Template base class? Easily acheived by
+defining your own Template class in a Python module, for example::
+
+    import Cheetah.Template
+
+    class CookbookTemplate(Cheetah.Template.Template):
+        _page = 'Cookbook'
+        author = 'R. Tyler Ballance'
+        def pageName(self):
+            return self._page or 'Unknown'
+
+**Figure 1. cookbook.py**
+
+For this example, I want all my subclasses of the `CookbookTemplate` to define a 
+page author which will be used in some shared rendering code, to accomplish this
+my templates will need to subclass from `CookbookTemplate` explicitly instead of 
+implicitly subclassing from `Cheetah.Template.Template`::
+
+    #import cookbook
+    #extends cookbook.CookbookTemplate
+    #attr author = 'Tavis Rudd'
+
+    ## The rest of my recipe template would be below
+
+**Figure 2. recipe1.tmpl**
+
+
diff --git a/sources/recipes/precompiled.rst b/sources/recipes/precompiled.rst
new file mode 100644
index 0000000..4480724
--- /dev/null
+++ b/sources/recipes/precompiled.rst
@@ -0,0 +1,59 @@
+Precompiled Templates
+=====================
+
+Why bother?
+-----------
+Since Cheetah supports two basic modes: dynamic and precompiled templates, you have 
+a lot of options when it comes to utilizing Cheetah, particularly in web environments.
+
+There is added speed to be gained by using pre-compiled templates, especially when
+using mod_python with Apache. Precompiling your templates means Apache/mod_python
+can load your template's generated module into memory and then execution is only
+limited by the speed of the Python being executed, and not the Cheetah compiler.
+You can further optimize things by then pre-compiling the generated Python files 
+(.py) down to Python byte-code (.pyc) so save cycles interpreting the Python.
+
+
+Basic Pre-compilation
+---------------------
+Suppose you have a template that looks something like this::
+
+    #attr title = "This is my Template"
+    <html>
+        <head>
+            <title>\${title}</title>
+        </head>
+        <body>
+            Hello \${who}!
+        </body>
+    </html>
+**Figure 1. hello.tmpl**
+
+In order to compile this down to a Python file, you need to only execute the 
+`cheetah compile hello.tmpl` command. The results will be a Python file (.py) 
+which you can then treat as any other Python module in your code base.
+
+
+Importing and lookup
+--------------------
+Typically for the template in *Figure 1*, I could easily import it post-compilation
+as any other Python module::
+
+    from templates import hello
+
+    def myMethod():
+        tmpl = hello.hello(searchList=[{'who' : 'world'}])
+        results = tmpl.respond()
+
+**Figure 2. runner.py**
+
+*Note:* If you use the `\#implements` directive, `respond` may not be your "main 
+method" for executing the Cheetah template. You can adjust the example above in 
+*Figure 2* by using `getattr()` to make the lookup of the main method dynamic::
+
+    def myMethod():
+        tmpl = hello.hello(searchList=[{'who' : 'world'}])
+        mainMethod = getattr(tmpl, '_mainCheetahMethod_for_%s' % tmpl.__class__.__name__)
+        results = getattr(tmpl, mainMethod)()
+
+**Figure 3. Dynamic runner.py**
diff --git a/sources/recipes/staticmethod.rst b/sources/recipes/staticmethod.rst
new file mode 100644
index 0000000..53192e1
--- /dev/null
+++ b/sources/recipes/staticmethod.rst
@@ -0,0 +1,54 @@
+@staticmethod and @classmethod
+==============================
+
+Refer the Python's documentation if you're unfamiliar with either 
+`@staticmethod <http://docs.python.org/library/functions.html#staticmethod>`_ or 
+`@classmethod <http://docs.python.org/library/functions.html#classmethod>`_ and their uses in Python, as they
+pertain to their uses in Cheetah as well. Using `@staticmethod <http://docs.python.org/library/functions.html#staticmethod>`_ it's 
+trivial to create *utility templates* which are common when using 
+Cheetah for web development. These *utility templates* might contain
+a number of small functions which generate useful snippets of markup.
+
+For example::
+
+    #def copyright()
+        #import time
+        &copy; CheetahCorp, Inc. $time.strftime('%Y', time.gmtime())
+    #end def
+
+**Figure 1, util.tmpl**
+
+Prior to version **v2.2.0** of Cheetah, there wasn't really an easy means
+of filling templates with bunches of these small utility functions. In 
+**v2.2.0** however, you can decorate these methods with `#@staticmethod` 
+and use "proper" Python syntax for calling them, **fig 1** revisited::
+
+    #@staticmethod
+    #def copyright()
+        #import time
+        &copy; CheetahCorp, Inc. $time.strftime('%Y', time.gmtime())
+    #end def
+    
+**Figure 1.1, util.tmpl**
+
+With the addition of the `@staticmethod <http://docs.python.org/library/functions.html#staticmethod>`_ decorator, the `copyright()` 
+function can now be used without instantiating an instance of the `util`
+template class. In effect::
+
+    #from util import util
+
+    <strong>This is my page</strong>
+    <br/>
+    <hr noshade/>
+    $util.copyright()
+
+**Figure 2, index.tmpl**
+
+
+This approach is however no means to structure anything complex, 
+`@staticmethod <http://docs.python.org/library/functions.html#staticmethod>`_ and `@classmethod <http://docs.python.org/library/functions.html#classmethod>`_ use in Cheetah is not meant as a 
+replacement for properly structured class hierarchies (which 
+Cheetah supports). That said if you are building a web application
+`@staticmethod <http://docs.python.org/library/functions.html#staticmethod>`_/`@classmethod <http://docs.python.org/library/functions.html#classmethod>`_ are quite useful for the little snippets 
+of markup, etc that are needed (Google AdSense blocks, footers, 
+banners, etc).
diff --git a/sources/recipes/writing_a_recipe.rst b/sources/recipes/writing_a_recipe.rst
new file mode 100644
index 0000000..6b1cbaa
--- /dev/null
+++ b/sources/recipes/writing_a_recipe.rst
@@ -0,0 +1,4 @@
+Writing a "Recipe"
+=================
+
+This document isn't quite there yet ;)
diff --git a/sources/roadmap.rst b/sources/roadmap.rst
new file mode 100644
index 0000000..48fe964
--- /dev/null
+++ b/sources/roadmap.rst
@@ -0,0 +1,27 @@
+Cheetah Roadmap
+===============
+
+Cheetah v2.2
+------------
+The first release in the v2.2 series (*v2.2.0*) introduced an overhaul of 
+Cheetah's string handling to convert everything internally to use `unicode()`
+objects instead of encoded string buffers. 
+
+The subsequent releases in the v2.2 series are planned to have a number of 
+important upgrades to Cheetah's infrastructure:
+
+* Built-in Django support
+* Cleaner code generation 
+* Finish and document #defmacro support
+
+Cheetah v2.3
+------------
+*still in planning*
+
+The third major series in the Cheetah 2 line of releases will have one focal point, **performance**
+
+Cheetah v3.0
+------------
+*still in planning*
+
+Cheetah 3000 will be the seminal milestone for running Cheetah on Python 3.0