Anatomy of a PHP App July 27, 2008
PHP is one of the most popular website-powering server-side code languages. Why? Because all PHP apps are essentially the same as each other. A bold statement no doubt, but is it so hard to believe? All these apps/websites/scripts are based upon data. This data can be stored in a database (postgresql, mysql) or in files (flat-file systems), PHP files always fall into the following two categories: interpreter files and doer files.
Interpreter files: these interpret the data, they get the data, and then they display it. For example, a blog post, co-ordinates on a map, a forum topic and it’s replies. No matter how complicated the website, this is all they do. Sometimes they edit and mould the data (converting times, encryption, etc), but then they display it, which is the crucial point.
Get data >> play around with data >> display data
Doer files: these are sent requests from interpreter files (via a html form, header() GET content, or POST content through the use of fopen). They grab this data, which is either a) an update to the current data or b) an entirely new data-set. Either way, they then insert or update the relevant database/files to reflect this. Upon completion, they redirect the user back to the interpreter file, which shows the user that a change has occurred.
Get data >> insert/update a database or file system >> redirect to interpreter file
Thus, all PHP apps should follow this simple, repeating pattern:
Interpreter file, user clicks and or enters data >> data sent to doer file >> database/files updated >> back to the start
I have found that, in my latest PHP app (one that may or may not ever become public), this very simple analogy helps in my coding. Due to the extremely complex nature of the app I am attempting to create, splitting all files into “interpreters” and “doers” makes my life infinitely easier. I have two folders, one for each, and within those folders are my functions and doer files. Upon this basic structure, anything is, in theory, possible (within the general bounds of PHP itself).
I have yet to see an exception to this rule, the only “difference” would be when people combine the two files, especially in very basic apps such as a contact form or user login. Despite that, those files are split into the two “sections” of interpreter and doer.
Oh, I don’t post big posts often, so if you liked it and want more, diggles it!
4 Responses to “Anatomy of a PHP App”
Leave a Reply
About
Hey! I'm Nick Barrett and this is Pointless Ramblings. I work as a freelance web design/developer, student and co-founder of Kerplunc. Read more »
Links
I no longer use del.icio.us, because it's unorganized. I use bookmarks, an app by me, for me! Of course, anyone can use it too though. It's unfinished, to work it you'll need a Kerplunc Account, register one here.
When I get around to making such a thing, latest links will magically reappear :)
Gaia Online
Have a guess at my password and hijack the admin capability of this blog: here :)
July 27th, 2008 at 3:24 pm
Good explanation, a lot of php programmers don’t even get this part of it :-p
July 27th, 2008 at 3:48 pm
Thanks, I don’t even think I quite understood until two days ago when I drew up the “theory”. It really does help in development though!
July 28th, 2008 at 1:05 pm
Nifty. But is PHP apps being “essentially the same as each other” necessarily the reason for PHP’s popularity? Surely that sort of applies to other development languages/frameworks.
July 28th, 2008 at 6:24 pm
Indeed the idea of data and the two file types applies, but the simplicity in the way PHP can do that also makes it popular. Of course, there are other reasons (it’s better resource wise than RoR, especially in multiple user environments) being one of them.