removed some crap that has been done and some stuff that is no longer…

… relevant

TODO

@@ -46,47 +46,11 @@ TODO Items (many are just ideas. This is not an official roadmap!)
   * If an input file ends in a dot, intelligently add the input extension if
     not found.
 
-- ##null: throw this comment away, do not place it in the compiled template
-  module in any manner.  Useful for obsolete text, unfinished text, or notes
-  to yourself.  Do for single- and multi-line comments.
-
-- Split out the code needed to run the generated
-  python into a base class of Template, and derive the compiled Python class
-  from that?  This would allow precompiled templates to be loaded much more
-  quickly. @@TR: I've done some of the refactoring neccessary to support this as
-  part of the 0.9.16 release.
-
-- A further 'nice to have' optimisation would be to be able to specify at
-  compile time that you are not using filters, Webware transactions etc, and not
-  generate code that uses them.  This would remove the need to import
-  DummyTransaction and the Filters module.  It would also simplify the code and
-  function calls in the compiled template module. @@TR: I've done some of the
-  refactoring neccessary to support this as part of the 0.9.16 release.
-
 - Debugging tools.  See section below.
 
-- Add --error option to compiled templates and "cheetah fill".  It would
-  activate the Echo error catcher for debugging.  (Maybe --list-errors to
-  suppress output and instead list the not found placeholders?  Less
-  important.)
-
 - Provide a utility to list the names of all placeholders in the template.
   Requested by Tracy Ruggles on Feb 21, 2003.
-
-- implement some better error handling for misformed #for, #if, #try directives,
-  etc.  At the moment these errors are not caught until Python executes the
-  code. @@TR: not a high priority as the python barfs suffice.
-
-- create a better error message for invalid syntax when a $var inside a 
-  directive is enclosed in ${} or $(). E.g.:
-     #include raw source=${x}
 
-- Delete whitespace before a comment on the same line.  The methods are
-  Parser.eatComment() and Parser.eatMultiLineComment().  It's already
-  working if the line contains 'STUFF#slurp   ## comment'.  Need to make
-  it work for 'STUFF    ## comment' (but retain the EOL newline).  
-  @@TR: is this really needed?  It seems a bit 'magic' to me.
-
 - 'errorCatcher None' to stop catching errors in the middle of a template.
 
 - Utils.WebInputMixin: factor out Cheetah-specific code so it can be used in
@@ -281,17 +245,8 @@ http://spyce.sourceforge.net/doc-tag_new.html
 
 Test Suite
 ================================================================================
-- test cases for the SkeletonPage framework @@TR: I have no interest in this as
-  I plan on removing SkeletonPage.
 - add cases that test the cheetah-compile script
-- add cases that test the integration with WebKit.  Since these must be called
-  from a running WebKit server, make a servlet that runs the tests and outputs
-  diagnostics to the browser.
-
-Website
-================================================================================
-- automate the documentation update 
-- See if we can get WebKit working on Sourceforge...
+- add cases that test the integration with various webdev frameworks
 
 Examples
 ================================================================================
@@ -304,47 +259,3 @@ Examples
   a database.
 - Pickled templates?
 
-
-CheetahX: pie-in-the-sky (notes from Mike Orr)
-========================================================================
-These ideas are being considered for Cheetah 2.0.
-
-- There are five distinct objects in Cheetah which should have a clearer
-  separation.
-
-  1. TEMPLATE DEFINITION:  a string.
-  2. TEMPLATE METHOD:  the method that implements the desired template
-       (which may be the Main Method or a #def/#block method).  This is
-       inside the generated class, which is inside the generated module.
-  3. DATA:  the searchList, local variables, current filter, etc.   Everything
-       that changes at runtime.
-  4. INFRASTRUCTURE:  the internal code used by Cheetah to fill and maintain the
-       template.
-  5. SERVICES:  convenience methods from the infrastructure exposed to user.
-
-  Cheetah combines 2-5 into a single Template subclass.  CheetahX proposes to
-  keep these distinct, with defined containment and interfaces between them.
-
-- The TEMPLATE METHOD might instantiate an INFRASTRUCTURE object for each
-  fill.  The constructor arguments would be everything necessary to access
-  the DATA.  Perhaps the TEMPLATE METHOD can pass its own code block, making
-  its own locals/globals accessible directly.  This would be a bit 
-  unorthodox, but less so than the current practice of switching the
-  template instance's class on the fly.
-
-- For SERVICES, add a custom object to the searchList that knows how to
-  access the protected INFRASTRUCTURE data.
-
-- Push more work into INFRASTRUCTURE, to insulate the TEMPLATE METHOD from
-  implementation changes.  For instance, replace every placeholder lookup
-  with a simple INFRASTRUCTURE method call, and let the infrastructure
-  do all the processing.  (It can use the code block mentioned above to
-  access the searchList and current filter.)  For local variable
-  lookups, you can call another method and pass the value directly.
-  For caching, I guess you pass in the cache time (or a special constant)
-  as a separate argument, and let the INFRASTRUCTURE maintain the cache.
-
-- The Template class needs to be split up into stuff nececssary to fill
-  a template (the INFRASTRUCTURE), and stuff necessary to comple a template
-  (which is not necessary for using precompiled templates, and slows down
-  Cheetah's import time).