Recommend this pageIf this page was useful to you, please recommend it to fellow websurfers:
You may rate this script by simply clicking on the appropriate star (5 stars is the best rating).
Smarty requires a web server running PHP 5.2 or greater.
When it comes to templating in PHP, there are basically two camps of thought. The first camp exclaims that “PHP is a template engine”. This approach simply mixes PHP code with HTML. Although this approach is fast from a pure script-execution point-of-view, many would argue that the PHP syntax is messy and difficult to maintain when mixed with presentation. PHP works well for programming, but not so well for templating.
The second camp exclaims that presentation should be void of all programming code, and instead use simple tags to indicate where application content is revealed. This approach is common with other template engines (and other programming languages), and is the approach that Smarty takes. The idea is to keep the templates focused squarely on presentation, void of application code, and with as little overhead as possible.
There are many benefits of separating PHP code from templates, some of which are:
No different than PHP being an abstraction layer on top of C to simplify development, Smarty is an abstraction layer on PHP to simplify template maintenance.
A common question: “Web designers have to learn a syntax anyways, why not PHP?” Of course web designers can learn PHP, and they may already be familiar with it. The issue isn’t their ability to learn PHP, it is about the maintenance of PHP mixed with HTML. tags are simpler, more intuitive, and less fragile than PHP statements. Templates also restrict what can be put in a template. PHP makes it too easy to add code into templates that doesn’t belong there. You could teach designers the rules of application design, but this should be unnecessary (now they are developers!). The PHP manual is intended for developers. Designers would only need a small fraction of this manual, and it doesn’t make it easier for them to find what they need. Smarty gives web designers exactly the tools they need, and gives developers fine-grained control over these tools. Numerous features are also available for presentation such as template inheritance, which maximizes template re-use and streamlines organization.
Although Smarty gives you the tools to make a clean separation of presentation from application code, it also gives you plenty of room to bend those rules. A poor implementation (i.e. injecting PHP in templates) will cause more problems than the presentation separation was meant to resolve. The documentation does a good job of indicating what things to watch out for.
Under the hood, Smarty compiles copies of the templates as PHP scripts. This way you get the benefits of both template tag syntax and the speed of PHP. Compilation happens once when each template is first invoked, and then the compiled versions are used from that point forward. Smarty takes care of this for you, so the template designer just edits the Smarty templates and never has to manage the compiled versions. This approach keeps the templates easy to maintain, and yet keeps execution times extremely fast. Since the compiled versions are PHP, op-code accelerators such as APC or ZendCache continue to work on the compiled scripts.
Template inheritance is new to Smarty 3, and it’s one of many great new features. Before template inheritance, we managed our templates in pieces such as header and footer templates. This organization lends itself to many problems that require some hoop-jumping, such as managing content within the header/footer on a per-page basis. With template inheritance, instead of including other templates we maintain our templates as single pages. We can then manipulate blocks of content within by inheriting them. This makes templates intuitive, efficient and easy to manage.
This label indicates that I could install the script without major problems and I could run the script without the need for major modifications to the original code (except for the usual configuration, of course). The label does, on the other hand, not indicate that scripts without this label would not work properly. The missing of the „tested & working“-label just indicates that I did not yet test these scripts.
This label indicates that the owner of this website uses this script / application for his own projects with success and satisfaction. This does, however, not indicate that these projects could not have been realized using other scripts / applications as well or that other scripts would not fit the demands of other projects as well or even better.