[PHPTAL] Browser Based TAL Inspection Tool
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. 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. So, before I begin my journey into the heart of PHPTAL to figure this out, has anyone dealt with something similar? Do you have suggestions on where to start looking? Or, preferably, is there a way to accomplish the above using hooks already provided by PHPTAL? Darrell Hamilton, Software Developer, 4over, Inc darre...@4over.com 818-246-1170 ext. 285 ___ PHPTAL mailing list PHPTAL@lists.motion-twin.com http://lists.motion-twin.com/mailman/listinfo/phptal
[PHPTAL] Proposal: Auto-fill slots with #ids
When creating typical web page we all use #ids, and something like: layout.html metal:define-macro=html metal:define-slot=content index.html metal:use-macro=../layout.html/html metal:fill-slot=content And most probably content will be div id=content. So maybe just to make our work easier PHPTAL should also fill directly element with defined ids? layout.html metal:define-macro=html div id=contentsome text/div index.html metal:use-macro=../layout.html/html div id=contentthis will replace some text in master template/div What do You think? ___ PHPTAL mailing list PHPTAL@lists.motion-twin.com http://lists.motion-twin.com/mailman/listinfo/phptal
Re: [PHPTAL] Proposal: Auto-fill slots with #ids
I totally disagree that we all use #ids :) When it comes to styling or semantic markup, ids have no advantage to well-choosen classes. It is rather problematic because there are some bad things about ids: * They mess up CSS specificity because there are way too strong * They have to be unique which may lead to invalid html markup in the long run * ... So I think we shouldn't mess up the clean and concise syntax of phptal only to support something I wouldn't agree with at all. My two cents worth... Per Am 19.08.11 12:22 schrieb aaatoja unter aaat...@o2.pl: When creating typical web page we all use #ids, and something like: layout.html metal:define-macro=html metal:define-slot=content index.html metal:use-macro=../layout.html/html metal:fill-slot=content And most probably content will be div id=content. So maybe just to make our work easier PHPTAL should also fill directly element with defined ids? layout.html metal:define-macro=html div id=contentsome text/div index.html metal:use-macro=../layout.html/html div id=contentthis will replace some text in master template/div What do You think? ___ PHPTAL mailing list PHPTAL@lists.motion-twin.com http://lists.motion-twin.com/mailman/listinfo/phptal -- webfactory GmbH Per Bernhardt, Anwendungsentwickler Lessingstraße 60 53113 Bonn Germany Fon +49 228 9114455 Fax +49 228 9114499 www.webfactory.de p...@webfactory.de Geschäftsführer: Sebastian Kugler, Matthias Pigulla Handelsregister: HRB 8673, Amtsgericht Bonn ___ PHPTAL mailing list PHPTAL@lists.motion-twin.com http://lists.motion-twin.com/mailman/listinfo/phptal
Re: [PHPTAL] Any updates to translation tools?
On Sat, 06 Aug 2011 17:07:05 +0100, Anton Andriyevskyy x.meg...@gmail.com wrote: (sorry for late reply, I've originally sent that e-mail from wrong account!) I still want to help and finish translation of phptal documentation to russian language (previously started and done 40% of chapters or so). I see php introduced very good online tool to do such things: https://edit.php.net/ If it is opensourced, maybe you can setup it so we all can help to translate phptal documentation? PHP's tool looks like a quite complex beast. I think DocBook is too complex to maintain already, and instead of piling more tools to deal with it, I'd rather get rid of DocBook and switch to something simpler, e.g. Markdown. To do this, I need: * tool to convert DocBook to Markdown (or HTML to Markdown): https://svn.motion-twin.com/phptal/trunk/doc/en/book.xml * tool to generate multi-page HTML with code syntax highlights from Markdown (existing scripts might be reusable: https://svn.motion-twin.com/phptal/website/highlight.php) Any volunteers? -- regards, Kornel ___ PHPTAL mailing list PHPTAL@lists.motion-twin.com http://lists.motion-twin.com/mailman/listinfo/phptal
Re: [PHPTAL] Any updates to translation tools?
On the Convert DocBook to Markdown item, there seems to be at least a handful of tools that can convert from HTML to Markdown. I'll see about putting aside some time to play with a few to figure out if there is a better or best option among them and, seeing if there is something that can go directly from DocBook to Markdown without the extra step. Are there any additional requirements, beyond just being able to convert? Is this going to be a one time thing? (I assume 'yes') Does it need to be scriptable? (again, I assume 'yes') Darrell Hamilton, Software Developer, 4over, Inc darre...@4over.com 818-246-1170 ext. 285 2011/8/19 Kornel Lesiński kor...@geekhood.net On Sat, 06 Aug 2011 17:07:05 +0100, Anton Andriyevskyy x.meg...@gmail.com wrote: (sorry for late reply, I've originally sent that e-mail from wrong account!) I still want to help and finish translation of phptal documentation to russian language (previously started and done 40% of chapters or so). I see php introduced very good online tool to do such things: https://edit.php.net/ If it is opensourced, maybe you can setup it so we all can help to translate phptal documentation? PHP's tool looks like a quite complex beast. I think DocBook is too complex to maintain already, and instead of piling more tools to deal with it, I'd rather get rid of DocBook and switch to something simpler, e.g. Markdown. To do this, I need: * tool to convert DocBook to Markdown (or HTML to Markdown): https://svn.motion-twin.com/**phptal/trunk/doc/en/book.xmlhttps://svn.motion-twin.com/phptal/trunk/doc/en/book.xml * tool to generate multi-page HTML with code syntax highlights from Markdown (existing scripts might be reusable: https://svn.motion-twin.com/**phptal/website/highlight.phphttps://svn.motion-twin.com/phptal/website/highlight.php ) Any volunteers? -- 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
Re: [PHPTAL] Browser Based TAL Inspection Tool
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
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
