New on his blog today Fabien Potencier tackles a tough topic for the PHP community - templating languages and whether or not their that useful/good after all.

So, you think PHP is a templating engine? So did I... for a very long time. But recently, I changed my mind. Even if PHP can be used as a templating engine, the syntax is just plain ugly as a template language. [...] So, when I asked a few days ago about the best and popular templating engines in PHP on Twitter, some people naturally answered "PHP" itself. I was not even surprised as that would probably have been my answer some weeks ago too.

He suggests that PHP, by itself, just isn't good enough any more and that truly robust templating languages (no, not like that one) can make a huge improvement in the quality of your application. He touches on a few related points including reusability, security and some of the current templating tools for PHP - Smarty, PHPTAL, eZ Components templates, Dwoo, Calypso and his own incarnation - Twig. He also includes some stats on rendering times and memory usage for each.

UPDATE: After all of the response that the PHP gave back to this article, Fabien also posted a follow-up with a bit more information on Twig.

Vid Luther has a new post to his blog showing how to switch the storage engine only one (or any number of individual tables) in your MySQL-backed Propel/Symfony project.

I need one MyISAM table in my schema, I'm using Symfony 1.2 and Propel 1.3. As flexible as Symfony and it's YAML files are, Propel currently doesn't allow you to change the storage engine on the fly. [...] So, the next best thing to do now is to have it so that when Symfony runs propel:insert-sql, I can piggyback my own SQL to it. Luckily, this is possible, and it's explained here.

He gives an example of how he's doing it - making a simple alter table script, putting it into a SQL file and pushing it out into the project's setup via a "propel:insert:sql" command.

The Enterprise PHP Magazine has pointed out some facts (slightly skewed, it seems) about the availability of a few different types of programmers, PHP included, according to several search engines.

I updated the estimation so we can have most accurate results. The table below illustrates the results found, I have just truncated Bing results to 1M to have more readable chart, after all I don't believe there are 50M resumes indexed by Microsoft - and that's another topic.

The results show about 780,000 PHP-related resumes on Google, 541,000 on Yahoo and the (obviously incorrect) 59,700,000 from Bing.com. There are a lot of PHP developers out there, but I can't imagine quite that many. Either way, even the numbers from the other search engines come in over the counts of the other three languages.

Antony Dovgal has announced a tool that can help you find out where issues are in your code - specifically places where too much work is being done and gumming up the works. The Pinba statistics server for PHP that gathers UDP data from the PHP processes and makes it available for parsing/graphing.

What is it? It's a daemon gathering information sent by PHP processes by UDP. In the same time Pinba acts as a read-only storage engine for MySQL, so you can use good ol' SQL to access the data. [...] There is no need to store that information for further analysis, therefore Pinba doesn't actually store the data - it keeps it only for 15 minutes (you can change that, of course), which is more than enough to update graphs.

You can find out more about the project on its (wiki) site including links to the latest downloads (version 0.0.3 at the time of this post).

Federico as mentioned the support that the Google App Engine has added for Java. This also means that you can run PHP in it through Quercus (a Java implementation of PHP).

Google App Engine now supports Java, this means that you can write PHP applications using Quercus: Demo script

You can find more information about this setup in this blog post from the Webdigi blog.

In Matt Curry's most recent blog entry he looks at the creation of a CakePHP plugin that integrates Yahoo! Search BOSS (Build your Own Search Service) into an application.

I mention that Neil's code would make a really cool plugin. This sparked a discussion as to whether this was possible with Cake's current plugin architecture. The issues where: how to get the datasource configuration, which would normally go in /app/config/database.php, how to reference the datasource class itself and how to handle the custom route.

The created the plugin with a ConnectionManager instance that goes out and loads in a configuration file inside of his search model in his application.

On the heels of some previous comments concerning the Smarty PHP templating engine, Quinton Parker has posted some of his own thoughts concerning the past and future of the tool.

Today's rant is about the Smarty templating system for PHP. A recent blog post by Paul M. Jones has rekindled my strong feelings against Smarty. Honestly its nothing personal. Its just I can't believe developers are still using Smarty or that they ever started using it. Unthinkable.

Quinton talks about when he first discovered patterns and N-tier including the Model-View-Controller pattern. This naturally lead to needing a templating engine for the views, but from everything he could tell about Smarty it "solved the wrong problem" (he chose phpsavant instead). He even points out an author who, despite writing a book on Smarty, still came back and said that there's no need to use something like that in an application.

Looking for a PHP template engine to sit on top of the business logic of your site? Well, Paul Jones suggests you say "no" to Smarty:

I just discovered nosmarty.net in my Solar referer logs. I have little love for Smarty, so it's nice to see this [comment about the current state of the engine].

Be sure to check out some of the comments to the post - they range from opposition to Paul's opinions ("Way to encourage respect for other people's work") to comments on the nosmarty.net site itself.

Kae Verens has a few tips to help simplify your life with your current content management system by using one code base to run multiple sites.

I haven't studied how other engines do it, but here's how I do it. First off, some benefits to sharing the CMS across separate sites: reduced resource usage, easier upgrades, easier bug-fixing. Convinced yet? Of course you are. Here's how you do it.

There's four steps to his process:

• Separate out the site-specific files from one another
• Serve all site-specific files out through a "proxy" script that can intelligently grab the needed ones based on the site
• Override the default configuration at request time (forcing it to use that "proxy" script)
• Create that proxy file that the web server can funnel the requests through (his example is included).

In a recent blog post, Jani Hartikainen looks at a two things that might make templating tools a bit more useful - better than just dropping data into a template.

Most template engines simply wrap PHP (or some other language's) syntax into their own syntax, and maybe they look a little bit cleaner when mixed with HTML. Some may even provide useful features like automatic variable escaping to prevent XSS vulnerabilities. But does this actually significantly reduce the amount of code needed to write some common scenarios, or make it easier to read/manage the code?

His two things revolve some bits of more advanced functionality - automatic table display (given whatever data) and automatic filtering of the data to make of less hassle on the developer/template designer. He even mentions an interesting idea of putting callbacks or validation checks into the actual XML definition tags for forms.