Re: [PHPTAL] Browser Based TAL Inspection Tool

2011-08-19 Thread Kornel Lesiński
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


Re: [PHPTAL] Browser Based TAL Inspection Tool

2011-08-19 Thread Darrell Hamilton
Kornel,

Thank you for the input on the macro parsing.  I'm not sure what I did wrong
the last time I tried, but I was able fix up my prefilter to successfully
pull out the metal attributes.

Darrell Hamilton,
Software Developer,
4over, Inc
darre...@4over.com
818-246-1170 ext. 285


2011/8/19 Kornel Lesiński kor...@geekhood.net

 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/phptalhttp://lists.motion-twin.com/mailman/listinfo/phptal

___
PHPTAL mailing list
PHPTAL@lists.motion-twin.com
http://lists.motion-twin.com/mailman/listinfo/phptal