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