summaryrefslogtreecommitdiff
path: root/TODO
blob: 775d664ff9f9e31a8d98b30ad0e305bab13bc696 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
Cheetah TODO list
-----------------
* If you are working on a task please put your initials at the end of the
  description
* When a task is completed please remember to note it in the CHANGES file
* Unresolved bugs are listed in the BUGS file.  Resolved bugs are be listed
  in the CHANGES file if the bug is considered significant enough and it
  affected a released version of Cheetah.


Requirements for 1.0
=========================================================================
- write a formalized grammar for Cheetah in BNF (MO)
- update User's Guide about changes to SkeletonPage (no more #settings,
  etc) (TR)
- Decide on Cheetah's 1.0 license and update the Users' Guide. (TR)


Other TODO Items
================================================================================

- Debugging tools.  $dumpSearchList() reduces each searchList element to a
Python primitive type (using dir() on non-dictionaries) and prints it using
pprint.pformat() with a comment before each: "*** searchList[1] ***".
Boolean argument 'all' adds local variables, builtins, etc.  Boolean argument
'allExceptLarge' skips any element with >20 variables, printing a warning:
"skipping, ### variables".

- revisit parsed #include directives.  Are they necessary at all??
  (This is a rhetorical question.  They are necessary.  However, the
  Users' Guide needs better examples about when and when not to use
  #include.  Also, consider making '#include' do a raw include, and
  something else do a parsed include ('#include parsed', '#include cheetah'?),
  so that users get parsing only if they explicitly request it.

- 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.

- create better error message for bad code such as:
  ##cache
  This is a cached region.  $voom
  #end cache

- 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).  

- 'python setup.py uninstall'.  This may require hacking an uninstall feature
  into distutils.

- 'errorCatcher None' to stop catching errors in the middle of a template.

- Finish up changes to #indent so that it matches the Users' Guide. (MO)


Rewrite the caching framework
=============================
- add #cache varyBy= (tied to Tavis' proposed caching framework for Webware)

- #cache test= with a one-variable test produces invalid Python (an empty
  if-block).  Example in Cheetah Developers' Guide, section
  "#cache with test: expression and method conditions".

- #cache id= seems to be ignoring the ID and generating a random numeric
  ID instead.  Is it working?  Do cache IDs have to be numeric?

- Other ideas in Tavis' head.

- Have an option to refresh the cache whenever an external
  file is updated.  This would allow a data structure to be kept in
  sync whenever its text configuration file is changed.



local/global/builtin variable lookup
==============================================================================
Cheetah currently does not allow users to override Python's builtin functions.
This provides safety because it prevents users from overriding e.g. $str and
breaking Cheetah horribly.  However, it also prevents users from using common
placeholder names such as $file, $max, $property, etc.; often requiring
convoluted circumlocutions to shadow a database field that's named one of
those.  Worse, the application developer (template maintainer) can't be sure
the user's version of Python won't have a new builtin defined that will make
the template fail.  

Related to this is the question of whether to use bare variable names for
lookup of local/global/builtin variables.  Currently at compile time, Cheetah
looks for a local/global/builtin variable and, if found, generates a bare
variable name.  If it's not found, it generates a a NameMapper lookup instead.  
Lookup of bare variable names is much faster, but it complicates the
implementation and may contribute to the can't-override-builtins problem.

To get rid of bare variable names in compiled templates, we'd need to add
the equivalent objects to the searchList:
    1) locals()
    2) "#set global" variables
    3) ... [user-defined searchList] ...
    4) self  -- the compiled template object
    4) globals()   -- for imported objects
    5) __builtins__
The order these objects appear in the searchList may be subject to debate.

#entry $func($arg1, $arg2="default", $**kw)
===============================================================================
Make a wrapper function in the .py template module that builds a searchList
from its positional arguments, then instantiates and fills a template and
returns the result.  The preceding example would create a function thus:
	def func(arg1, arg2="default", searchList=None, **kw):
		"""Function docstring."""
		sl = {'arg1': arg1, 'arg2': arg2}
		if searchList is None:
			searchList = [sl]
		elif type(searchList) == types.ListType:
			searchList.insert(0, sl)
		else:
			raise TypeError("arg 'searchList'")
		t = TheTemplate(searchList=searchList, **kw)
		return str(t)
##doc-entry: and #*doc-entry: comments are appended to the function docstring.
	Finally, make this function accessible directly from the shell.
If there are any non-option arguments on the command line, call the function
instead of filling the template the normal way.  
	This would perhaps make more sense as arguments to .respond().  But
.respond() has that pesky 'trans' argument that mustn't be interfered with,
and other programs may assume .respond() takes only one argument.  Also, 
when called via str(), str() cannot take arguments.
	

Upload File
========================================================================
A mixin method in Cheetah.Utils (for Template) that handles file uploads --
these are too complicated for .webInput().  The method should do a "safe"
file upload; e.g., http://us3.php.net/manual/en/features.file-upload.php ,
within the limitations of Python's cgi module.  The user has the choice of
three destinations for the file contents: (A) copied to a local
path you specify, (B) placed in a namespace variable like .cgiImport()
does, or (C) returned.  (B) parallels .webInput, but (A) will certainly be
desirable situations where we just want to save the file, not read it into
memory.  Reject files larger than a user-specified size or not in a list of
user-approved MIME types.  Define appropriate exceptions for typical
file-upload errors.  Method name .webUploadFileAsString?
	One situation to support is when  form has a text(area) field
related to a file-upload control on the same form, and the user has the choice
of typing into the field or uploading a text file.  We need a method that
updates the text field's value if there is an uploaded file, but not if there
isn't.  This may be handled by the regular method(s) or may require a separate
method.


Test Suite
================================================================================
- test cases for the SkeletonPage framework
- 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...

Examples
================================================================================
- create some non-html code generation examples
  - SQL
  - LaTeX
  - form email
- Template definitions in a database.  .py template modules in a 
  database?  Caching template classes and/or instances extracted from
  a database.
- Pickled templates?