基于XML的模板引擎与Smarty lexer
There was a lot of excitement about Smarty 3 and its new lexer and how much more power it would give you as a template designer, but when it actually hit the shelves as it were, it was a real disappointment how slow it was. Compiling a template from scratch took well over a second in Smarty 3, whereas the same template in Smarty 2 would take about half a second. Not good.
But it did get me thinking, why do you need to implement a full-blown language parser in PHP when it already has modules like DOMDocument, SimpleXML and the like available to it?
Are there any template engines for PHP that are based on the XML extensions and/or DOMDocument? If so, what is the performance like? If not, then has anybody attempted to write one?
One drawback I can forsee is it would only really be useful for XML-based formats such as XHTML and RSS. For generating other outputs (Non-XML HTML, plain text, CSS, etc) it would potentially be quite problematic, though I'm sure you could get round it with CDATA blocks. Are there any other implications for using XML/DOM for template parsing that I've not considered?
有很多关于Smarty 3及其新词法分析器的兴奋点以及它给你带来多大的力量 模板设计师，但当它真的上架时，它真的令人失望，它有多慢。 从头开始编译模板在Smarty 3中花了一秒多的时间，而Smarty 2中的相同模板需要大约半秒钟。 不好。 p>
但它确实让我思考，为什么你需要在PHP中实现一个完整的语言解析器，因为它已经有像DOMDocument，SimpleXML等可用的模块？ p>
是否有基于XML扩展和/或DOMDocument的PHP模板引擎？ 如果是这样，性能如何？ 如果没有，那么有人试图写一个吗？ p>
我可以预见的一个缺点是它只对基于XML的格式（如XHTML和RSS）有用。 为了生成其他输出（非XML HTML，纯文本，CSS等），它可能会有很大问题，但我相信你可以用CDATA块来绕过它。 使用XML / DOM进行模板解析是否有任何其他影响，我没有考虑过？ p> div>
On your point about Smarty, IIRC Smarty uses "compiled templates", so if the performance issue you mention is only in the "compile phase" is becomes a moot point - each template only compiled once, thereafter the template content is output from (much faster) cache.
The problem with using an XML parser is that HTML isn't always well formed XML. Even if you use valid XHTML you can end up jumping through hoops to support HTML entities, and then you'll find corner cases like embedded Javascript, etc. (On a side note, IMO this is HTML5's biggest failure - it doesn't deprecate all that legacy SGML crap and insist on using well-formed XML. If the HTML committee had done this then future templating engines would be much easier to write using standard XML APIs.) I wrote an XML-based template engine some time ago, this uses the XMLReader API, but to make it work with HTML you have to add entries in to your Libxml system catalog. This works well enough but is a pain, most people would just give up and use something simpler.
Here are some of the XML-based template engines I know of:
http://code.google.com/p/querytemplates/
http://www.hyperkit-software.com/projects/phptemplates/index.html
In terms of performance, I don't think most XML-based template engines are significantly faster in the compile phase - most modern template engines for PHP use compilation, so performance of the compiler is generally sacrificed in favor of a more extensible and maintainable engine codebase, as well as producing more optimized compiled templates. As Robin pointed out, because the templates are compiled, no one really cares how fast or slow the compilation phase may be.
There are other arguments for XML-based template engines, however. Personally, I dislike the idea of mixing two different tag-syntaxes, one of which (Smarty) cannot be parsed, processed or validated using ordinary XML-tools. To clarify, yes, you can parse the XML portion of a Smarty template, but you cannot parse or modify the Smarty-tags, which look like text to an XML tool.
Another common argument against custom syntax (such as used in Smarty and most other template engines), is that PHP already has syntax for everything these template engines provide - for example, <?=ucfirst($person->name)?> is similar to {$person.name|ucfirst} in a plain PHP template. It uses a syntax that is already known to PHP developers, which means there is no learning curve, no compilation step, no engine that needs to be deployed, no runtime overhead to render the template, etc.