Possibly the most common sign of bad code is tight coupling, especially between logic and presentation. It might seem like a good idea to print out the HTML while the data is being generated, but it more often than not leads to a big incoherent mess of tangled code. [...] While PHP makes it unnecessarily easy to write shitty code it also provides a lot of ways to avoid it. I'll use this post to show you how ridiculously easy it is to create a template engine in PHP in three easy steps.

He includes the sample code for a "Template" class and shows the combination of exporting variables and output buffering to return the resulting template populated with values. The "__toString" method makes it so that you can just echo out the object and get the results.

So why do you need a search engine, is database not enough? If you create a small website it might not matter. With medium or big size applications it's often wiser to go for a search engine. Saying that, even a small websites can benefit from Solr if you desire a high level of relevance in search results.

Their example involves an ecommerce website and a search for a term (iPhones) and how difficult it could be to match against the possible multiple variations on the models. Solr makes this kind of searching easier. He shows you how to get a Solr instance all set up and configured as well as the PHP PECL extension from here. A sample PHP script is also included showing connecting to Solr, inserting a new document and searching for a simple query of "hello".

I was consulting and I would see significant server resources consumed by bootstrapping the apps. Loading config files, loading dependent classes, setting up dependencies, initializing ACL's, and the list goes on and on. One of the ways to negate the effect would be to cache a bootstrap object and then pull that object from the cache at the start of the request. However, the problem is that unserialization can actually end up taking more time than the bootstrap process itself.

He wonders if, after the initial bootstrapping happened, a method could be called (his example is "init_engine_state") that would cache the Zend Engine's current state and pass that to a callback function. This would cache everything - objects, variables, classes, etc - all pre-interpreted into memory and make them easy to reuse on future executions. What do you think? Share your thoughts in the comments of the post.

Templating is a real hot button in the web development community. [...] The high horses that people usually get on are that all too familiar TLA MVC (Model/View/Controller) architecture and "separation of presentation and business logic". The poor pedestrians upon which they look down are those who have written "spaghetti code" - templates where presentation logic, markup, business logic, database access configuration and whatever else you might imagine are mixed up in the same file. Well, I've got some news for you: you're all wrong.

He points out that, with most of the major templating tools out there, there's most people still put some sort of business logic in their templates. Rarely will you find a "pure" template that only echoes out the data. He gives an example of a Mustache template with "empty" logic in it. He shares a new term his coined too: "Template Animation". This is the separation of the templating process as it is usually done and splitting it so that the output is a modified DOM resource rather than a static template.

He talks about some of the advantages of this approach and an example of its use in an example of a logged in user vs not logged in user as well as a brief discussion of Markdown/HAML.

The only thing that Template Animation advocates is that the technological barrier between the frontend and the backend is never crossed - that our templates are truly logic-less.

There's lots of comments on the post already - everything from support of the idea to systems that already implement this sort of idea to disagreeing opinions.

A couple of weeks back I had to write a solution for a client to track the referrer search engine from where the user came to his sites contact page, without using Google Analytics. If a user was to fill the contact form on the website, the referring search engine name and the keyword for which it was refereed was to be emailed along with the contact information. The following is a solution for the same.

The code itself is pretty simple - it checks the $_SERVER['HTTP_REFERER'] and, based on an array of search engine types, looks for a certain "query" keyname in the URL and matches what follows (with a regular expression). This can be useful for not only determining what sort of audience is visiting your site, but could also be used to present a custom message to visitors from certain search engines (or, more complicated, to show different content based on search terms).

In this article I'll introduce five of PHP's most popular templating engines, providing you with a basis for continuing your own investigations. Keep in mind however that this list is by no means definitive; if you have experience using a templating engine not discussed here, please tell us about it in the comments!

The five template engines the author chose to spotlight are:

• Smarty
• Dwoo
• Twig
• Savant3
• PHPTal

Each comes with a description of its major features and a code snippet or two showing it in use.

When we think about PHP Template Engine, the most famous library is certainly Smarty. However, we may consider other alternatives to Smarty. In this post we have collected 16 template engines written in PHP that allow you to separate HTML code from PHP code.

Among those on the list are templating engines like:

• Smarty
• Savant
• Dwoo
• PHP XTemplate
• h2o-php

In my last post I created a small (and very personal) test of different templating engines in PHP (Smarty, Haanga and Twiw). Someone posted a comment asking for the comparison between those template engines and old school phtml. OK I've done some tests. It's a bit difficult to create the template inheritance (without cloning one of the template engines and creating a new one) so I have one approximation with a simple include. It's not the same but it's similar.

He tries to recreate a similar scenario as in the three other templating tools by setting up a base template (with inline PHP), a class to populate the contents of it and a sample template with "inheritance". He stacks up the execution times and memory usage against the results from the other three with interesting results, specifically compared to Haanga.

Template engines has a lot of features but I normally only use a few of them and the other features very seldom. In this performance test I will check the same features under different template engines to see the syntax differences and the performance. The template engines selected for the test are Smarty, Twig and Haanga.

He does some testing with each, creating a basic template to loop and create a basic table (template code and PHP code included) as well as an example using template inheritance with each. The reports of his tests are shared at the end with stats for memory used and execution time for both the normal templates and the inherited versions - but you'll have to check out the post for those results.

In the previous segment of this article, I introduced you to Dwoo, a powerful, PHP 5.x template engine that allows Web application developers easily separate the user interface of their application from its business logic. [...] In this second, and concluding, segment, I'll delve a little deeper, exploring some of Dwoo's lesser-known features.

He talks about the ability for template inheritance, creating sub-templates (like partial views), plugins available, mail merging, caching and how to use it as the templating engine in your framework of choice.