You can also place translation markers in the HTML to replace specific HTML blocks with tranlated versions (espessically usefull when the grammer mix of variables, text and HTML differes in different languages). It also has the long term benefit of encouraging you to remove all the langage specific code from the application and put all output words etc. into the template.

Of course this is still wonderfully undocumented - but has been tested on some very high traffic sites, in a few european and a few double byte languages.

First tranformation would be a language independant template & language xml to produce a language specific template which then cached and then feed content xml to the final result.

Writing a xslt which produces an xslt maybe bit too much hassle. Possibly could automate (with a few more transforms) this somewhat thou.

I am a little surprised that the php community hasn’t glommed on to clearsilver templates (http://www.clearsilver.net/) with the php bindings (http://www.geodata.soton.ac.uk/software/php_clearsilver/). Clearsilver forces a clean separation between business logic from presentation logic. You can localize an application by simply switching the hdf data files. Bloglines.com is using this technology for their recent internationalization efforts.

Everyone has their own preferences for template engines but many huge applications (bloglines, google groups 2, yahoo groups, Plaxo) are using clearsilver. The ability to swap out the back end programming language and leave your templates entact is convenient.

culley

I’ve been tempted to experiement in using double xslt transforms for producing interm templates.

Could be this makes interesting reading. Markus says good things about the relationship between XSLT and Haskell.

I am a little surprised that the php community hasn’t glommed on to clearsilver templates

Thanks for the link. Now glommed.

I really like the phrase “Just in Time Code Generation.”

Thanks - hadn’t occurred to me while writing - wonder if it makes the same league as Moore’s Law? Could also make a nice subheading in a book on PHP project management, under “Meeting Client Expectations”…

PHP generating PHP code is an old story. If you just think of Smarty and most other template compiler engines, you realize that using PHP to generate PHP code has been done for many years now.

Smarty concept of compiling templates into executable PHP code was started in this thread of list php-template. If you prefer newsgroup access you may find the thread here:

news://news.php.net:119/4598.84T2941T13386538mlemos@acm.org

The idea of antecipating template processing to a compile time stage and generate executable PHP code was taken from one of the modules of the MetaL engine.

Smarty generated code is not as efficient as the code generated by the MetaL engine template module but that is another story.

Anyway, after Smarty many template compiler engines appeared imitating Smarty’s approach, but all were written in PHP.

As a side note, regarding the use of the MetaL engine for generating PHP code, Metastorage is the largest PHP code generator application that I have written based on MetaL.

Despite it comprises now about 44,000 lines of code, Metastorage usage is simple, throughly documented, and the gains in productivity and code efficiency and overwhelming because the developer does not have to spend an iternity on tedious jobs like writing repetitive code, testing and debuging manually.

I have recently launched the PHP Classes support forums using Metastorage to generate classes that act as interfaces to store the forum, threads, messages, subscriptions objects in a persistent storage container (read the MySQL database of the site). I am very happy with the gains in efficiency.

Back to the subject, besides template compilers, there are many types of code generators written in PHP. Besides the generators of PHP code listed in CodeGeneration.net, which are not all written in PHP, you may find here several classes written in PHP to generate PHP code for several purposes.

The bottom line is: if you open your eyes and realize that PHP can also be used to generate PHP code, you do not have to learn yet another language and probably write PHP generators more proefficiently.

One quote from you article, Harry :-)

Before I go any further I should mention that, as you’re probably aware, PHP is not the only choice for writing command line scripts. Both Perl and Python, to name just two, are widely used for writing command line applications and, in many cases, make better a choice than PHP. They provide a mature set of tools for common problems and, typically, better performance.

So, why use PHP? An obvious — and very good — reason may simply be that you know PHP better than the alternatives. Less obvious is that, if you’re developing a Web application in PHP, writing supporting scripts in another language can lead to extra headaches — even if you’re confident in both. There’s both the human aspect of having to switch programming “mind sets”, and the overhead of having to support two platforms and the potential missed opportunities for re-use; data access logic may need to be implemented twice, for example.
http://www.sitepoint.com/article/php-command-line-1

I actually prefer to write generators in a different langauge if I can. Otherwise escaping special characters which are also special in it’s own syntax can become a real nightmare.

The Empty use of “@” not clashing with PHP is a good example.

Adds to deployment hassles though, and your developers have to be “multilingual” in the programming language sense. Take your pick.

yours, Marcus