An analysis of the ITX templating system included with PEAR.
By : Ivan Stojic
In this tutorial, I'll explain and demonstrate how to use the ITX templating system from the PEAR collection of useful classes for PHP. As we go along, I'll show you some of the competitors, why I didn't like them and why in the end I choose to work with ITX in my own scripts.
We will build a simple example script that will load and fill out the data out of a database. This script will use another PEAR component, a database abstraction layer. If you are not familiar with PEAR's DB abstraction layer, I suggest you read up on that other tutorial :)
How things used to be
I started writing dynamic web applications back in 1997. PHP was in version 2 at that time, and wasn't yet called PHP, it's codename was FI. I never used it because I had a different toy.
My primary interest at that time was to write simple Perl scripts that would be embeded in the HTML code by using server side HTML parsing. It was simple, it only supported several simple "include" oriented commands and at that time it packed a punch.
Later on, I graduated to writing CGI applications. I started off with a pretty simple guestbook, and later progressed to message boards and similar simple user interaction scripts.
But, through all that work, there was something missing...
The need for clarification
At the time I was still too inexperienced to realize that there was something wrong with my code. The wrong part was, of course the fact that I mixed markup and code freely and that my scripts were highly dependant on the look of the host HTML document.
Every time the web site's look changed I had to go in and do the changes to the HTML that was printed from inside the script. This made workflow rather cumbersome because practicaly every designer had to have a programmer baby-sitting him.
Furthermore, the applications were difficult to customize on a per-client basis, because only somebody with an above average skill could do all the needed changes.
And finally the revelation
By that time PHP3 was starting to kick up dust so I focused on learning it and using it more and more in my day-to-day work. I started playing around with various ways of abstracting the output from the scripts. First of all I realized that HTML and code shouldn't be in the same file - hence I started doing simple abstraction by using the include() function.
The second idea was to separate some parts of the output from the scripts into configuration values. In that way, my users would edit only one configuration file and set various options. For instance, in my guestbook the administrator could specify what kind of HTML code would be printed before and after the sender's name, et cetera...
