Latest Development Style

I've revised my development style after a lot of thought. Now, don't get me wrong, I make exceptions to this when I have a client with certain tastes, but this is the style I will use when the client leaves it up to me.

First, if I can use small packages to achieve what I need, I'll definitely consider them. I'm not a big fan of big elaborate systems except things that are well established and which fit a need very well. For example, WordPress and phpBB are great fits on some projects -- no need to rewrite those unless something special comes up.

Now, if I need to build something custom, then I don't like spaghetti code, so I need a framework. I don't like the learning curve of other frameworks, and I have learned a few, but they are either too cumbersome, too slow, too inflexible, or just generally are a plain in the rear to use.

Therefore, we have to separate out the PHP from the MySQL from the XHTML, so here's how I do it.

First, I used to use Smarty, and will still use it if a client wants it. However, now that I know Smarty, I've realized that it's actually slower, as well as redundant to, just using XHTML files saved as PHP pages with inside. I stick these in a subfolder called templates and load them with require_once instead of $smarty->display.

Second, to handle the MySQL, I use either Outlet ORM with PDO or Propel ORM with PDO, depending on client need. And if I have something special, some special SQL besides this, I do a straight PDO call by using parameterized SQL stored in a central conf file. (BTW, my conf files are actually PHP class files with public variables.) Parameterized SQL means I have SQL statements with ^ caret symbols inside where variables would go, and I use a Pack() function that I created to insert the variables inside those places.

Third, to handle the PHP page logic, I don't use MVC. Instead, I use PHP pages for each individual need, and each PHP page is started with a commented template where I insert my PHP logic. I call these "PHP Logic Templates".

Fourth, instead of a "Model" from MVC, I use a classes subfolder with my object classes inside.

Fifth, I use Blueprint CSS on difficult CSS projects, but now I often may go straight CSS based on things I learned from Blueprint. It makes for cleaner code to go without Blueprint, but it's not always possible.

Sixth, I still use everything else such as ProperCase() function naming, $sAdaptedHungarian for my variable naming, initial curly braces { on the same line as the statement where they are used (not on a new line), and everything else you see in previous posts besides the stuff about the database logic, which has changed a great deal now.

ORM -- Oooooooh. I get it now!

After years of doing parameterized SQL centralized in a class of public variables (named a conf file), I think I finally see the light on why an ORM is useful.

Here's why:

• The conf file would get huge on a project.
• Several developers working on a project might obliterate each other's conf file under some conditions.
• I would spend like 40 hours (over the entire course of a 3 month project) reviewing the best way to do something in SQL statements, when I could have been coding.
• It's easy to make a syntax error in the SQL and not recognize it for a couple days.
• I had to actually write all that SQL -- no tool would generate it for me.

However, with an ORM, here's the fix for all that:

• No huge conf file for the SQL. You can split the database logic into classes that some guys can have, or that other guys can have, as their tasks.
• I don't have to write out all that SQL for most of the project. Instead, I can focus on the code. Sure, if I want to build a difficult JOIN and type the SQL manually, nothing is stopping me from doing that, though.
• Not having to write out all that SQL, there's far less chance for a bug to appear.
• Subclassing is a beautiful thing in the right context.

So, I recommend you consider an ORM tool soon. And my favorite right now is Outlet ORM because of its small file size, the fact that it's very well written, has no bugs that I can find, and is well suited to many uses.

My Way of Doing Database Work

Right now, I use MySQL. It's what 95% of my clients are running. Now, don't get me wrong -- I love PostgreSQL and SQLite as well, but MySQL is where the cash is and where almost 100% of all the PHP sitescripts out there are based upon. If I needed a site that really had to scale for several hundred thousand users, then, hands-down, it would be PostgreSQL. And if I had a site where I invented something cute and a quick and dirty database file would do, then SQLite might be a consideration for me, or if I need an embeddable solution, then SQLite would do as well.

Now, in PHP5, you have Pear::DB, Zend_DB, PDO, mysqli, and mysql API in interacting with that MySQL database. However, all speed tests show that mysql API is the fastest except when doing prepared SQL statements. For prepared SQL statements, mysqli API is the fastest. So, since I don't use mysqli-type prepared statements, I use the straight mysql API.

Wrapping that API is very important to me. It lets me swap databases or control a problem from a central place. I stick it in a $db class and I have methods like Run, RunFast, GetRows, GetRowFromRows, GetNextRow, GetRowCount, GetColCount, Translate (builds a simple SELECT statement on the fly), and so on.

After working on enough projects, no one likes find a project where the SQL is sprayed all over the place. So, you'll find my SQL in a single class file with public variables storing parameterized SQL statements where ^ is the symbol I use to indicate where a value would go. I call it like so:

require_once('DB.php'); //this already instantiates the $db object for me in the class file
$sSQL = $settings->SQL_GET_USERS_BY_LASTNAME;
$db->Pack($sSQL, 'Smith');
$rsRows = $db->GetRows($sSQL);
while ($db->GetNextRow($rwRow, $rsRows)) {
   echo $rwRow['email'] . "<BR>\n";
}
$db->Release($rwRow);
$db->Release($rsRows);

And in my $settings class, you'll see something like:

$this->SQL_GET_USERS_BY_LASTNAME = "
SELECT
   *
FROM
   users
WHERE
   disabled = 0
   AND lastname = '^'
ORDER BY
   firstname;
";

See how much cleaner it is to use this sort of technique?

[EDIT: See my post on July 9, 2008 where this is superceded.]