Blogs » Dynamically Typed » A Development Infrastructure for PHP

A Development Infrastructure for PHP

PHP Blog: Dynamically Typed

by Harry Fuecks

Nov 2nd, 2004 @ 2:42 AM MST

Just ran into A Development Infrastructure for PHP which discusses a generalized strategy which Tony uses when building applications with PHP. He clarifys some of the design decisions further in the FAQ.

Think Tony's done an excellent job - it's an end to end view of the approach he's evolved for building web applications and is also more or less a first - I've yet to see anyone be bold enough to describe a complete PHP architecture in this kind of detail. There's alot of valuable insight in there and get the general impression of "sanity" (i.e. taking into account PHP's inherent advantages and disadvantages). Think there's plenty ammunition here for Marco.

Tony has also written up his thoughts on a number of other PHP-related subjects plus some excellent information on XML and XSL. Reading his ideas on workflows right now.

(Post a comment)



Thanks for the links. Will start reading them as soon as possible.

Lots of interesting articles making their way onto the net now.

  Posted by: ausurt Nov 2nd, 2004 @ 4:20 AM MST



I'm really starting to get into the Developer's Library series of books from Sams' Publishing and recently purchased "Advanced PHP Programming". Almost all of the topics covered here are also in this book (I don't think it covered XSLT in depth). I've only gotten to Chapter One after perusing through the table of contents, and I'm already enjoying what I'll be getting in to. PHP5 has truly emerged as a triumphant push for Open Source web technology.


  Posted by: malikyte Nov 2nd, 2004 @ 8:42 AM MST




I found the MVC link about a year ago and found it all useful, and only recently visited again to see some new stuff posted for PHP5 :)

Kept meaning to post the url but never got around to it, must admit that I was impressed with the entire site myself though ;)

A useful resource that I'd advise everyone to bookmark, cosidering how selfish (:eek:) I've been in not posting the MVC url way back last summer :D

  Posted by: Version0-00e Nov 2nd, 2004 @ 9:45 AM MST



thanks for the link harry :) that site is full of informative articles, though i might say it reeks of arrogance :P can't blame him though, i'm sure he's a very well-experienced and bright software engineer

  Posted by: andre Nov 3rd, 2004 @ 12:26 AM MST



Agreed...definitely informative, and definitely arrogant.

  Posted by: cholmon Nov 3rd, 2004 @ 6:10 AM MST




Well not using any javascript is not going to get you anywhere these days ...

I am also not convinced that defining a global xslt to render all your data into different output formats is a viable solution for most cases and for the cases where this is a viable alternative you can just as well write the given sutff in php itself. In my framework I use php as my template language, so inside a template I can render pdf, html or even send an email if I so choose.

  Posted by: lsmith Nov 3rd, 2004 @ 8:20 AM MST



calm down folks :lol: a very imformative site though i didn't sense anything arrogant about it?

In my framework I use php as my template language, so inside a template I can render pdf, html or even send an email if I so choose.

Send an email? are you not breaking some rule or other on seperation of concerns? i like web standards, they're there for a good reason.

to transform data to a html format or a pdf format or what ever else you care, you only need to alter one stylesheet and nothing more.

in your framework you need to alter a template and proberly also the php that goes with it as well, going by your own comment, is the feeling im getting anyways.

but if it works for you, then that's good.

  Posted by: Version0-00e Nov 3rd, 2004 @ 10:19 AM MST



I've been increasingly exposed to folks who insist on staying away from javascript for the sake of browser compatability, so I'll second lsmith's comment. Proper use of javascript is very helpful, if not mandatory, for today's web applications.

As for the global XSL stylesheets, I get the impression that his framework/infrastructure focuses much more on the functional aspect of any given application, as opposed to its ability to flawlessly adapt to any sort of presentation layer. Assuming the layout/look and feel of the site is pretty constant and predictable, I can see how a framework like this would save gobs of time. But like any framework, it's not a perfect solution to every problem.

  Posted by: cholmon Nov 3rd, 2004 @ 11:34 AM MST



Arrogant? Moi? Whatever gives you that idea?

  Posted by: Tony Marston from Nov 3rd, 2004 @ 12:27 PM MST



no offense tony :) your site is very informative but you do have a way of dealing with those whose views differ from yours. anyway i think those guys you criticized in your oop article are arrogant.

  Posted by: andre Nov 3rd, 2004 @ 11:49 PM MST



What I am saying is that you can have a generic converter written in php just as well. The idea behind xslt stylesheets is to be able to transform xml. For that you first need xml. Then you can define all sorts of stylesheets that transform that to html, pdf etc. You can transform xml via php just as well. Without having to move to a totally different way of thinking (coding xslt is very different from php).

However most of the time we have to hand tweak the given output to exploit the advantages and issues with the given display formats.

So the big advantage of being able to use the various off the shelf converters is only really apparent if you have learned xslt for some reason or another quite well (which the author in question apparently has) so that you feel very at home with xslt and if you have content which you dont need to optimize much in terms of formatting.

  Posted by: lsmith Nov 4th, 2004 @ 4:39 AM MST



While I agree that it is easy to use a templating system written in PHP I already knew some XSL before I starting learning PHP, so I went with the devil I knew. I have never regretted that decision. I currently have a web application containing 350+ transactions which are handled by less than 10 generic stylesheets. Can any other templating system do that?

Tony (a legend in his own lunchtime) Marston :)

  Posted by: Tony Marston from Nov 4th, 2004 @ 10:46 AM MST



I read (everything on) your site, Tony, and found it very enlightening - thank you.

A problem I continually have, when reading various literature on the subject or perusing sitepoint's forums or various informative web sites, is with the seperation between the Business Logic and Data Access Logic.

Don't get me wrong - I get it; its a very worthwhile ideal to be able to switch the way you store your data and maintain the same business logic, or use your data in a new way by simply creating new components in the business logic without having to change the data access Logic.

But the two seem inexorably tied together in a practical and realistic sense. After all, what is your business logic without data to work with, and at that, should your business logic really be able to handle ANY data you pass to it? Is that healthy?

Let me use the example of the User class, something I'm sure we're all familiar with. Suppose one of the properties of a "user" is "username". You whip up your User class, then you whip up a UserMapper class, which has a method insert(User). The internals of this method inevitably make specific reference to the properties of a User object AND inevitably make specific reference to your method of storing the data (even with a DAO you need to specifically state where you are putting the info... "INSERT ... WHERE username = etc).

So now, instead of releasing your data access from the tied-down clutches of your business logic, you've tied it down to both the business logic AND the extremely specific data storage mechanism.

Perhaps what I am trying to understand is whether or not people are really serious when they talk about seperation of logic. When you add a new property to your theoretical user, you're going to have to add it in the User class, then add a place to put it in the data storage mechanism, and lastly, you've got to change the functions that map your class to your data storage.

Perhaps I'm missing the point here - so please, set my disillusioned mind to rest by clarifying what I'm getting wrong here.

I do see the benefits in being able to use the User class in any number of ways and always being able to instantiate a UserMapper to insert(User), but what is the difference from having this code internal to the User class in a practical sense (as opposed to the "because OOP is right" reasoning).

  Posted by: JNKlein Nov 4th, 2004 @ 1:58 PM MST



In reply to the previous post from JNKlein here are my (arrogant?) views on the subject of separating business logic from data access logic:

The primary purpose of having a separate object in the data access layer (sometimes known as a Data Access Object or DAO) is that is should be possible to switch the entire application from one data source to another simply by changing this one component. Thus if I want to switch my application from MySQL to PostgreSQL (or whatever) I simply change my DAO.

In order to make this work in practice my own implementation is as follows:

(a) Each business entity (eg: customer, product, invoice) has its own class. This identifies the structure of the associated database table plus all the business rules required by that entity. Each of these is actually a subclass of a generic table class which contains sharable code that can be applied to any database table.

(b) When the business object gets instructions to update the database it does so via an insertRecord(), updateRecord(), or deleteRecord() method which contains the entire $_POST array. This is validated according to whatever rules have been defined within that particular subclass. If there are no errors it will talk to the relavant DAO in order to perform the database update.

(c) The DAO also has the insertRecord(), updateRecord() and deleteRecord() methods, but as well as the validated contents of the $_POST array it is also given a second array which contains all the table structure details. Using these two arrays it is easy to construct the relevant SQL query string before calling the relevant database API.

In this way my business object contains business rules, but no calls to database APIs, and my DAO contains calls to database APIs but no business rules. This is clear separation of logic.

Switching from one DBMS to another is simple to achieve in my infrastructure. In my generic table superclass I have a variable called $dbms_engine which is set to 'mysql' or 'postgresql' or whatever. This will then apply to all database tables unless overridden in any individual subclass. When the business object wants to talk to the data access object it first needs to instantiate an object from a class which is defined within a separate include() file. The name of this file is in the format 'dml.<engine>' where <engine> is replaced by the contents of variable $dbms_engine. I have a separate version of this include() file for every DBMS that I use. All I need to do before accessing a new DBMS is to create a new version of the 'dml.<engine>' file and I'm up and running.

Another advantage of this mechanism is that it would even be possible to talk to different database tables through different DBMS engines within the same transaction. Hows that for flexibility?

In case you want to see these (arrogant?) theories put into practice I have created a sample application which is described in This contains links where you can run the application online as well as download all the source code and run it on your own machine. You can then examine the source code and tell me what I am doing wrong.

BTW, in your example you mentioned have a User class and a UserMapper class. Why two? I can put everything I need into a single class, which is what encapsulation is supposed to be about.

  Posted by: Tony Marston from Nov 5th, 2004 @ 4:29 AM MST



I 've considered the logic layers separation in a Web Application many times. And the only thing that keeps me from efectively using it is that it's main function (independence of user interfase, business rules and data storage/retrieval) only helps when migrating or extending to other script-language/data engine/platform. But this only happens very very few times in an Application Lifetime. In the other hand, this versatility has the invonvenience of not taking advantage of each platform/engine/language optimization benefits (which usually are not compatible between them), and this lowers the application performance, affecting the consecuences directly to the users. So the question here is Versatility vs Performance. I believe that we must not punish the users by using this "development shurtcuts". This, of course, is considering that you care about your application performance. (i'm sorry if I misspelled some words. I'm from Argentina)

  Posted by: Cochambre Nov 5th, 2004 @ 2:18 PM MST



Oochambre said: <quote> The separation of presentaion, business and data access logic only helps when migrating or extending to another script-language/data engine/platform. But this only happens very very few times in an Application Lifetime. </quote>

Your view of the benefits of the 3 tier architecture are very narrow as in reality they are not restricted to changes in the scripting language, database engine or platform.

As my article is about building web applications with PHP, and PHP can run on many platforms, any argument about not being optimized for a particular platform is rather empty.

Being able to change from one database engine to another by changing just one component is not just a fancy expensive option that is rarely used. Take the case of MySQL, for example. For versions up to 4.0 you must use the mysql_* functions, but for 4.1 and above you must use the mysqli_* functions. How complicated would that be if you had hundreds of scripts to change instead of just one? You must also consider the case where a supplier creates an application which is then run on customers own machines with the database of their choice. If it is coded so that it only runs with MySQL but they actually want PostreSQL or Oracle or whatever then how difficult would it be to cater for the customer's needs?

Having presentation logic separated from business logic has other advantages besides a switch to a totally different user interface device (for example, from client/server to the web). In the first place the creation of efficient, artistic and user-friendly web pages requires more than a passing knowledge of (X)HTML and CSS (and perhaps javascript) which a lot of PHP coders are without. The people with these skills may have little or no abilities with PHP, so by having separate layers you can have a different set of experts to deal with each layer. Another more common requirement is to have the ability to change the style of a web application with relative ease. By ensuring that all output is strict XHTML with all style specified in an external CSS stylesheet it is possible to change the entire 'look' of an application by changing a single CSS file.

In my infrastructure all my XHTML output is produced from a small set of generic XSL stylesheets, which means that should I need to make changes to my 350+ screens that cannot be done by altering the CSS file then all I have to do is change my generic XSL stylesheets, which are currently about 10 in number. You may think that such changes are rare, but what about when the time comes to convert your existing web application from HTML forms to XFORMS, the latest W3C standard? I can do that by changing 10 XSL stylesheets. Can you?

  Posted by: Tony Marston from Nov 6th, 2004 @ 5:24 AM MST



Just wanted to let you guys know that I started a thread on the Sitepoint forums to continue this discussion:

  Posted by: JNKlein Nov 10th, 2004 @ 11:04 AM MST



Unfortunately my opinions were attacked with such ferocity and foul language in that thread that the moderator was forced to close it to further postings, so I was unable to defend myself against the last set of attacks.

This puerile behaviour against someone whose only "crime" is to dare hold an opinion which is not "politically correct" forces me to believe that the forums on this site are not a place to exchange new or different ideas.

  Posted by: Tony Marston from Nov 18th, 2004 @ 9:46 AM MST



Take a look at for a summing up of the terminated thread.

  Posted by: Tony Marston from Nov 26th, 2004 @ 3:54 AM MST



Mad. Quite, quite mad.

  Posted by: McGruff Dec 4th, 2004 @ 7:48 PM MST



I found Tony's site a while ago now and recently went back to show a few friends, tutor's, and lecturer's his site, articles and how well he defends his OO views. Now I see that he has been attacked so ferociously for daring to stand up for his different design patterns and methodologies. I think it's rediculous that people can call his code all the names under the sun - when it infact works perfectly well for him. Because he came up with this by himself and didn't follow your personal preference as many of you have come to follow and now become arrogant and stuburn, or just lazy to try anything different, you blast him.

At the end of the day, Tony's site and application framework does exactly what it says on the tin. Anyone who read's the code - and understands it (note this) can see. I am new to all this, but have certainly found this methodology the easiest to follow, the easiest to expand and modify to meet my needs, and certainly the quickest to develop in. I believe this is because unlike many of you, I am not biased towards any particular pattern or methodology because that's the way I currently do it. I'd just like to commend Harry for pointing everyone in the direction of Tony's articles, and Tony for standing up for himself. I'd also like to see anyone else create a php/database application framework, that is as expandable and easy to develop for as this. Before anymore criticism's are made against Tony's work, you might like to read a substantial amount of his articles first. Not just skim and look for things to pick at out of context - actually read. PS Tony my lecturers loved your site, and whilst watching them reading this site point thread I didn't know what they wanted to do most, laugh, cry, go around and punch the person in the face until they decided to give up the predispositions and accept something new. Everyone particularily enjoyed this: ***Lastcraft: I am not the slightest bit interested in your design and haven't looked at it. I am simply responding to your comments so far. I also feel a duty to defend the community spirit in this group, otherwise I wouldn't even respond. Really your posts barely belong in the advanced forum.*** ***Lastcraft: If you are completely ignorant of alternate solutions*** From the guy who is being completely ignorant to Tony's solution and the fact it works! Anyway, I've got a Final Year Project to do - and guess which framework I've decided to follow after two years of trial and error with ALOT of other methodologies. Yes, You guessed it! And my tutor loves the idea!

Keep up the hard work Tony!

  Posted by: Steve Daniels Dec 8th, 2004 @ 3:28 AM MST



Tony, I commend you for taking the time to write such well written and detailed articles. It has really opened my eyes and helped me get over the hump of learning OOP. I'm still studying the framework, and it looks very promising. The only concern I have is the performance.

Is there any way to implement some kind of cacheing mechanisms in your framework?

  Posted by: Glenn Dec 9th, 2004 @ 10:44 AM MST



I'm astonished to see comments from Harry that Tony Rantson has "valuable insight".

I'm terrified that learners might be exposed to the guache OOP material on his site.

I'm sad that Tony's personality flaws prevent him learning from more experienced programmers. Valid criticisms of his newbie-ish code are not personal attacks - just the opposite in fact.

Enough already. Let's not waste any more of our time.

  Posted by: McGruff Dec 9th, 2004 @ 2:42 PM MST



In response to JNKlein,

You made a good point, in that when something is changed in the database it also has to be changed in the class that handles the database. This has the potential to cause some problems, and the best solution would be one in which the database would not need to be changed in order to facilitate a change in the data handled-- the database structure needs to be flexible. I am working on using Tony's OOP methodology with EZpublish database structure, so that the database holds all of the content types (users, articles, links, etc.) in 4 tables using a virtual OOP approach. Any change to these content types would add another row in one of the tables, instead of requiring a change in the database. This way, the class that specifically works with a database table never needs to be changed if done right.

Seems to be the best solution to me.


  Posted by: allspiritseve Dec 17th, 2004 @ 9:42 PM MST


Post a comment -


OR log into the SitePoint Forums:





* denotes required field

Your Blogmaster is...

Harry Fuecks Harry Fuecks

Harry has been working in corporate IT since 1994, with everything from start-ups to Fortune 100 companies. Outside of office hours he runs phpPatterns: a site dedicated to software design with PHP that aims to raise standards of PHP development. He also maintains Dynamically Typed: SitePoint's PHP blog.

November 2004

1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30

Dynamically Typed Archives

Recently in Dynamically Typed

Suggest a Post

Got a good idea for an article/post? Spotted something for Harry might be interested in? Or maybe you just have a question? Let Harry know!

SitePoint Blogs