Though few are likely to have noticed, I have not been very active on the forum over the last couple of months. I started school in September, with accelerated classes in Linux installation and administration, and MySQL administration. The eighteen hours a week of lecture and lab, plus the reading, plumb wore me out. The second section started three weeks ago. The Apache administration class had insufficient enrollment and was canceled. That left only PHP. Thank gawd for that.

In the first three weeks, we have each installed our own Apache, MySQL and PHP from source. Plus, we have set up PEAR libs and installed the Smarty templating engine. Each class begins with a quiz on the previous lecture, and ends with a lab project based on the current lecture, plus we have an assignment related to the current week's studies. We will have finished the text by the end of the fifth week, and will spend the last three weeks on developing a web application. I suspect that it will be either a commerce site or something like a blog.

All that explains my lack of activity here, and brings me to the subject of this post.

Tonight's lecture was about abstracting the database so the PHP doesn't need to know which DB it's using or how it's using it. Likewise, templating removes the html from the code. The html guys can do their magic, presenting the data without screwing with PHP, and the PHP guys don't have to mess with the html.

The client tier has very similar needs. We don't want behavior mixed with our html. A change, let's say you're changing onclick event handlers, would mean editing every page that contains that client side scripting. Take it out of the html, and you don't care. One changed file propagates the new event handler throughout the site.

CSS lets us remove presentational markup from the html. No more font tags, or color attribute, or tables for layout or even inline style attributes. It's all in a separate css file, where a single change is applied site-wide.

The css newbie nearly always complains that the whole thing is overkill. The funny thing is, I was thinking the same about using PEAR and Smarty. I have the advantage of knowing the benefits of separation from my html/css/javascript experience. I'll get over the learning hump with PHP, and the css tyro will get over the hump, too. It is worth it.



I've been concerned with my

I've been concerned with my overall lack of advancement with PHP and keep dithering over things such as my lack of understanding of concepts like classes, realising that I'm definitely stuck in a beginners mire from which I need to claw my way out of, templating is another of those areas, having dealt a bit with CMS constructed around solid .tpl principles that concerned me. I have been looking at Smarty to get a start, but it interests me , your comments re abstracting and template separation of course are easily understood once once has grasped the concept in the CSS HTML sense but I do see a significant difference, with CSS/HTML I think it fair to say that this concept is a given, set in stone, the way it has to be, no arguments suffered, yet with the fairly complex nature of templating PHP I see it as having a very specific usage geared towards an overall app, but there would still exist the usefulness of PHP in being easy to quickly slot into html to provide simple minimal server side scripting. So in that sense although I get the point of templating I see it not so much as a given that we must separate PHP from HTML, but maybe I'm stating the obvious, and no one is implying otherwise Smile

I'm impressed though with your diligence don't think I'd have the energy or stamina to do that much schooling, I'm just struggling getting back some core Unix understanding.

Be careful with what you're

Be careful with what you're being taught. Separating your data access and your html generation from your application processing is good sense. The tools you mention may not necessarily be good sense.

PHP is a magnificent templating language. It doesn't really need smarty. Read this article, in particular the last paragraph:

Brian E. Lozier wrote:
In short, the point of template engines should be to separate your business logic from your presentation logic, not separate your PHP code from your HTML code.

The argument is that many template engines don't add anything that php doesn't have and do add a new language and extra complexity.

Its possible to make similar arguments about db abstraction layers. I don't think they are quite so convincing. DB abstraction layers generally provide higher level functionality, e.g. returning a complete result set without having to code fetch loops, neatly handling transactions/commit/rollback without you having to bother with all the individual error checks. But don't think you are making your application db independent. You are still writing SQL and that may well be db dependent.

For application design, you may want to take a look at the Model/View/Controller pattern and the series of articles on PHP and MVC at

@ Hugo: I'm looking forward

@ Hugo: I'm looking forward to the project portion of the course. It is very difficult to take one's self beyond the trivial.

OOP is a powerful tool that can make some things easier to do than they would be in structured programming. It is not easy for me to grok, and I have yet to take significant advantage of inheritance. Sad I do like the encapsulation of methods and properties that classes provide.

@ Chris: I do get your point on business logic vs presentation logic. To be fair, my instructor[1] made the same distinction. At this point, it is simpler for me to visualize as separation of program logic and html—analogous to removing javascript from the html. Not strictly true, but it gets me through the night.

As to templating engines, I don't know enough to argue with a gnat. From my experience with mixed html and PHP, a great deal of segregation would be a massive benefit. Is complete separation necessary? I don't know, but I suspect the more complete, the better (in theory). How to do it is in the air for me.

Abstracting the DB API is critical. PEAR is the tool for that, as far as I know. Even in my limited experience with DB driven pages, I've run into dealing with a change in the DB. Bringing all the various pages into compliance with a new DB API is a Royal PITA. The simplification of code is just icing on the cake.

As to the SQL statements, that is an issue no matter how you address the DB. If any query is used in more than one place, it should be put into an external file. Again, the programming logic would be DB agnostic.



[1] Our instructor is a supervising software architect for Southwest Airlines, based here in Dallas. I am impressed, if by nothing else, that he "gets it" where html and css are concerned. See Guillory at Stan does have a skin or two on the wall. Smile