Browse files

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

… relevant
  • Loading branch information...
1 parent 79b7705 commit 2b1d9df0c503f8c21a2bca6ee1e2395ade5f9415 tavis_rudd committed Jul 4, 2006
Showing with 1 addition and 90 deletions.
  1. +1 −90 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 @@
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.
-- automate the documentation update
-- See if we can get WebKit working on Sourceforge...
+- add cases that test the integration with various webdev frameworks
@@ -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.
- 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).

0 comments on commit 2b1d9df

Please sign in to comment.