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;
$attr->hide();
}
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
PHPTAL@lists.motion-twin.com
http://lists.motion-twin.com/mailman/listinfo/phptal
