[PHPTAL] back to the dom parser idea

[Laurent Bedubourg]

Hi everyone,

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 &nbsp;), 
>>>> 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 &pound; 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 
>> PHPTAL :)
> 
> 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.
> 
> 
> David
> 
> 
> _______________________________________________
> PHPTAL mailing list
> PHPTAL at lists.motion-twin.com
> http://lists.motion-twin.com/mailman/listinfo/phptal


-- 
Laurent Bedubourg
lbedubourg at motion-twin.com
http://www.motion-twin.com