under consideration

For generation of XML documents, add filters for validating the generated output for both document (page) and fragment levels. Should be easy to turn on and off, e.g. for development or for deployment.

Support for expression and directive level caching.

A quick test shows it can speed up rendering times by order 10 or greater in heavily repetitive cases. A general syntax (that may be applied equally to both directives and expressions) could be something like:

$directive[ condition ? cache(*keys) ]{ ... }

where condition is a boolean expression to be evaluated at template compile-time, and will determine whether the caching is applied or not e.g. for development or production scenarios, and *keys are simply keys of items (or, more generally, just arbitrary string expressions to be evaluated in the evaluation namespace) and will be used to generate a cache_key to represents the desired state as per the context.

Such a syntax can be applied identically also to expressions i.e. when no directive is present e.g.

$[ condition ? cache(*keys) ]{ ... }

For the implementation a caching library such as Beaker could be used, or an own simple memory based scheme adopted (a la collection.cache). Depending on the implementation, other general expression caching options e.g. cache_type="memory", could be exposed as **kwargs on cache(). There should not be any performance penalty for when the cache is inactive i.e. the cache check should be compiled out of the loaded template.

A cache() callable will be made available by default on the evaluation context.

Conditional expression-level decorators.

Generalize the cache idea above, to provide an open-ended mechanism to conditionally capture output of any dir/expr and do something with it -- but with the possibility of turning it on and off depending on context. E.g. for the XML fragment well-formedness validation, one could do:

$directive[ dev ? xml_validate_wf() ]{ ... }

that will, when the dev evaluates to True, intercept the output and do the validation check, raising an error on failure. On the other hand, when dev evaluates to False, the xml_validate_wf() interception will be compiled out of the loaded template.

Applications would also be able to add any such custom decorator to their template evaluation context.

Cache the compiled template on disk, for the benefit of faster startup times, appreciable for usage in a cgi environment.

Introspection into the collections and their respective caches of loaded templates.

Consider supporting a more convenient way to specify filters on expressions, e.g. ${ expr | url, trim, etc } would do the same thing as the current ${etc(trim(url(expr)))}.

Improve ability to "extract" pieces of text from files as the source of a template, without needing that those files be touched in any way. Criteria could be pairs of regular expressions, line numbers, format-specific parsing directives, combination of criteria, etc. Could be implemented as an extension to the evoque() built-in callable, or as a new callable such as extract().

done

Add documentation for defining custom quoted-no-more classes. Add sample implementations e.g. for url.

Support also for python 3.0, maybe from the same Evoque python 2.5 code base.

See the changelog.