So, I was messing around with the template parser a bit.
I came up with this functionality:
Stick:
{%load valid%}{%assure well-formed%}
...blah blah xml...
{%endassure%}
Within the assure block, text is checked for well-formedness by running
it through Expat. Parse errors are translated back to template syntax
errors with correct locations, see:
http://robert.wittams.com/wellformederror.png
I'm still not convinced it is actually useful in its current state, as
it doesn't take into account templatetags, included templates,
inheritance, conditionals etc, and it would be hard to do so. (have to
either delay all checking till output, or infer specialized runtime
checkers from context. Inheritance may be slightly easier and done at
parse time).
It just assures that the text nodes in the block would be a wellformed
xml document if they were all smooshed together with nothing in between.
So some things that would be well-formed on output would not be with
this, and some things which would be invalid on output would not be
caught by this. The best that can be said is that it enforces a
particular style which makes it easier to produce well formed output...
Strangely, even it its current form it did find a real error in one of
my pages ;-)
The point is really to see how far the template parser can be pushed. It
may be possible to have things like pages served up as HTML4 or XHTML
based on client headers, whilst you do everything in XHTML on the
server, stuff like that. Or well-formed or schema checking which can be
turned off in production. Etc etc.
It did point up some limitations in the parser. I had to run time
inherit from the parser in use (Parser vs DebugParser), and also
seperately wrap each bit of parser state. Kind of hackish. Also some
minor changes to methods in the parser class.
So I have some changes that I would like to make to the parser to make
this stuff 'easy' to do. Basically, delegating almost all parser
decisions to a chain of ParserPolicy objects. Debug would be implemented
this way as well. Composition over inheritance etc.
My main question was, are these changes things that people are
interested in? I don't believe that these things would affect general
use of the parser. But I'm also not certain that the things that would
make use of these interfaces would be things that everyone would want,
ie maybe they would go in contrib or out of tree.
This specific functionality may not really be useful, but I think the
parser changes would be interesting anyway for the future possibilities.
Rob
