Just a note to say that the XML parsing / PHP code generation
performance is not critical with PHPTAL because they are only done once
: when the template is modified (ie: nearly never compared to how many
times template are executed once in production).
IMO the XML parser should :
- have enough debug info (line numbers, node names) to help PHPTAL users
debug their templates
- support any kind of doctype, any encoding without bothering the user
requiring to specifying them inside each template
- be kind enough to support things like tal:condition="php:foo < bar"
which are not real errors and should not throw an exception which would
slow down development and make users unhappy
- support PHPTAL xml namespaces without bothering the user
- just help PHPTAL without getting in the way
As long as an XML parser does not fulfil these requirements (and some
other I didn't think of) and does not pass the PHPTAL unit tests (more
than a hundred) I recommend sticking to the current parser and improving it.
I don't mean that builtin PHP xml parsers are bad, I just mean that they
are not programmed to let applications manipulate XML the way PHPTAL has
to. And forcing them to behave the way we want is an endless hack fight :)
And congratulations to Kornel for his first PHPTAL release !
Good job :)
David Zülke wrote:
Am 27.01.2008 um 23:08 schrieb Kornel Lesiński:
There are issues with DOM itself:
- it doesn't report line numbers for elements, so error messages
(other than parse errors) can't include them. Not very user-friendly :(
It does! Just need to disable libxml error reporting, so no warnings
etc are generated, then pull the errors by hand.
But is there a way to get line number of any element if there were no
parse errors? Things like invalid TALES expressions need to report
line number, but aren't libxml's concern.
Then we validate using XML Schema or RelaxNG ;)
- non-validating parser can't support named entities (like ),
but users will expect them to work. Switching to validating parser
is not an option, because it will reject incomplete HTML fragments
and PHPTAL elements.
That is possible as well. Just need to tell DOM to resolve externals
and validate against them (= doctype). I think we can expect people
to write well-formed XML.
What DOCTYPE do you suggest? Document with XHTML DTD and TAL
attributes won't be valid, so something else is necessary.
No... well... could in theory append an HTML doctype to the document, or
an inline DTD with the entitiy definitions. Not a big problem :)
- parser decodes numeric entities and represents them as literal
characters, possibly exposing encoding issues.
Eh? what do you mean. As long as the charset info is correct,
everything is fine.
I meant that if someone didn't care about encoding, but just used
named entities like £ would have to add/correct all necessary
declarations. It's not a big problem.
In XML, you need to care about encodings ;) Tell the users that they
should write proper stuff, and problem solved <:
IIRC libxml will even read a charset value from a meta tag in an XML
document that it recognizes as XHTML.
Fortunately it does it only for HTML. XHTML user-agents must not read
charset from <meta> element.
Correct, but if someone delivers XHTML as application/xhtml+xml, he'll
also have the XML prolog with the charset, so again, no issue!
On a different topic, I really think we should use this DOM parser
approach as the foundation for a completely new PHPTAL. There are
some things that I think would be worth changing, for instance we
should mandate the use of braces in function calls. That not only
allows passing of arguments properly, it also eliminates the need of
runtime evaluation of the type of the given element (array index,
object property, object method). Not sure why it is as it is right
now, but the "original" TAL uses braces for method calls, too, IIRC.
I'm pretty sure Zope's TAL does not require use of braces/parens. It
even has nocall: modifier that prevents automatic calling of
functions, which would be unnecessary if calls required special syntax.
However optional parentheses with arguments for function calls sound
like a good idea. This can be done without a complete rewrite of
But we should still do that! ;)
Seriously, I'll be able to help with this stuff. Can dedicate a good
amount of time if we decide to start over, making proper plans,
roadmaps, feature sets etc. It would be an excellent effort I think.
PHPTAL mailing list
PHPTAL mailing list