[PHPTAL] back to the dom parser idea

Kornel Lesiński kornel at aardvarkmedia.co.uk
Sun Jan 27 23:08:49 CET 2008


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

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

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

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

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

-- 
regards, Kornel




More information about the PHPTAL mailing list