Grr @ Luggage Handlers

Well, I’m assuming this was the result of my luggage being thrown…

 Cracked Lens Filter

This occurred sometime between me handing my luggage to First Choice at Faro airport in Portugal and getting it home after traveling to London Standard. It’s an expensive lens filter but it saved the more expensive lens from damage and the SLR still works.

Given how luggage is treated (read: thrown) by handlers this is not surprising. I did however pack within a Lowepro Compudaypack which itself was within a large sturdy case padded by clothing.

Now to find a replacement filter…

Aww! Russian Kittens!


See the set on Flickr.

PHP Design Patterns

So recently I’ve been refactoring piles of code while providing multiple interfaces to it. It has taught me to separate various layers of logic out and I want to note them down for future reference.

You see, people often read code in books and articles without considering what type of problem the code solves. But understanding this one can author the code in the correct file and provide the most flexible (and proper) interfaces to it.

Take a list. You have a database and it contains a table with some data. Nothing particularly special. You write your first PHP script for it, to view the contents of that table, calling in list.php in your web htdocs folder.

You visit it and it works. You react with surprise that something of yours works first time. Or not.

Now you go modify your script’s output to work via smarty. Separation of PHP code and presentation is good, after all. You include for each record a link to edit.php with ?id=<record_id>.

Then you write edit.php with two things in mind: You want to first display the record as it stands but displayed as a form with editing facilities. On submission of a POST you save the submitted data in its place, or creating a new record if no <record_id> is present.

Wonderful. To top it off, you create a delete.php. Exercise your imagination here please.

Now you have a complete system to list, edit, add and delete your table’s contents.

That table contains some pretty useful data. Later on in your application’s development you need access to that data within another script. Or another web application such as an RSS feed writer needs access to it.

So do you create a second copy of list.php, with modified output? Or use list.php but detect the output expected and display the correct smarty template?

Well, at this point you should consider what business use the list has. When I say business use I do so in the loosest of senses. It could be a blog with no commercial value at all for all I care. Regardless, your application has a use for the list. And now it has two uses, or another application wants to use it.

The business use logic needs to be written between the code that performs the database query, and the code that answers the customer (or blog reader) request and spits out an expected result.

This business logic should be written as a class. I say this for one simple reason. A class can be thought of as a container in its simplest of forms. By putting the business logic in a container, calling the database query, performing any business-level actions, then returning the list of data to the calling script, you are ring-fencing your code allowing it to be used by many other applications.

Now at this point it can all go wrong. Things pivot on your experience as a programmer and as a user of web applications / sites. You might create each method of your business-logic class as static, allowing it to be called as a function utilising the class name as a namespace. Or you might decide to load an instance of your class with environment information and write a constructor and additional methods to cause the application to rebuild the world on each page request.

Neither is right or wrong. But here’s my point: The two decisions I’ve not yet mentioned are:

  1. Application specific behaviours
  2. Fault handling

Application specific behaviours. By this I mean taking the request from the customer (“consumer”) and working out that needs to happen for the expected output to be shipped out. This will involve calling your class, perhaps building an instance of it or obtaining the results of a static method. Either way you now have some data. And because you’ve written that in your list.php you know to send the data to smarty and call your list.tpl file. But it you were in your edit.php file, you would check for <record_id>, then check if the consumer was GETting (reading) the data for possible¬†changes, or POSTing (submitting) a new or changed record, calling your business logic class as appropriate, then picking an entirely different smarty template to ship the data in.

Fault handling. In your list.php if your class told you there were no records you can still display a list.tpl file, and the consumer would show nothing, or the list.tpl could detect this and say explicitly there were no records to view. Consider though that a different type of consumer, another web application, was asking for your list, one that had to use the web to access your data for some reason. You wouldn’t spit back an HTML page as that would be inefficient and not particularly friendly. Instead, some XML or just plain CSV/TXT records could be sent. Now here’s an idea, for such consumers, you could send an HTTP error code instead of sending all those extra bytes.

Now you see where having levels within your code, separated out could be more useful. A script to handle the types of requests, and classes to handle the business logic. The business logic cares not one jot what will happen with your data. Your individual scripts do, and can make decisions line by line themselves.

To most experienced programmers all this is like teaching the Bible to Jesus. But for the rest of your, hope this helps separate your code into better organised files.