On Fri, 19 Aug 2011 07:08:22 +0100, Darrell Hamilton <darre...@4over.com> wrote:

Even with a tool like PHPTAL, the array templates for extremely dynamic
sites can become difficult to manage, from a designer's point of view. So, my thought was to use prefilters to modify the rendered markup, dumping information about the original tal markup. Then, adding a javascript based (greasemonkey maybe?) inspection tool that would reveal things such as "what translation key generated this block of text" or "what macro did this block of html come from", giving designers, even developers, the ability to simply look at the site and click on the region they want to modify and be told
exactly where to find it's source.

That's a cool idea!

I think it could be easily implemented by modifying PHPTAL to leave TAL
attributes in the generated markup.

In Element.php in separateAttributes()

} else if ($this->xmlns->isHandledNamespace($attr->getNamespaceURI())) {
                $talAttributes[$attr->getQualifiedName()] = $attr;

if you remove $attr->hide(), then PHPTAL attributes will remain in the document.

Anyway, the i18n attributes were easy to deal with using a prefilter;
however, I came to find by the time the prefilters are triggered, all macros have been evaluated and placed inline, making it impossible to determine
what macro each block of markup belongs to.

No, macros are not inlined at compile time. Macro definitions are changed into functions: metal:define-macro creates function definition, metal:use-macro is a function call. If macro is in another template, then that template is loaded at run time as a separate file in a new PHPTAL object.

Anyway, prefilters are given access to template as-is, before PHPTAL starts messing with it.

regards, Kornel

PHPTAL mailing list

Reply via email to