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.

Time To Revisit PHP.Net

We don't know it all, even when we feel like we do.

Sometimes we get stuck in our ways and think we know it all. It's interesting how I am taught a thing or two by others. Anyway, if you haven't been over to check out the latest function list with PHP.Net, I suggest you do so. For instance, I used to do posted form data entry validation and filtering/cleanup with my own string functions and preg_ (pcre API) because I had my mind stuck back in the days of PHP4. Well, turns out that everyone's now using the new filter_ API, and there's a ctype_ API out there that I didn't even know existed.

Which do you think runs faster? A bunch of calls with preg_ API or one single call to filter_ or ctype_ API? Well, each time you use a function in the global namespace of PHP, that's a slight performance hit. Of course, that hit is faster than your own code with loops and if/then's because it's calling something in C, but at least consider that one C call is going to be faster than three or four C calls. So yeah, using the filter or ctype API is going to speed you up a slight bit.

Another one to look at is mcrypt API, if you were doing your own encryption by hand. However, you can still keep your old makeshift encryption functions on hand -- just do an extension_exists('mcrypt')) call to see which API can be used on a given server. Oh, and if you've never used extension_exists(), then neither have I until today. Again, go look over the PHP.Net stuff because there's lots of new stuff in there with PHP 5.2 or better.

Of course, your server may not have these features, but they should! You can either get your web hosting provider to upgrade to PHP 5.2 (or higher) or you can see if you can get them to add the filter API extension (even if beta).

Next, the more I use an ORM, the more I appreciate it. I should have used Outlet ORM (or any ORM, such as Propel) awhile back because I would have accomplished a lot more in very little time. And no, you don't have your hands tied with the ORM -- if you are working on a complex JOIN and don't want to fight with the ORM, then don't! Instead, go grab PDO or mysql API and bring it on, old-school.

Another piece of advice I received was to use APC to speed up the performance of my pages. You can get this from PECL with 'pecl install apc' at command line.

Some more advice I received was to use page recursion on form posting. I used to HATE this it. HATE, HATE, HATE, HATE!!! It was because it would confuse the heck out of me when inheriting code like this. But now I see the light. You see, it's far easier to do data validation and kick the user back to the same form with the data filled in and an error message than it is to redirect to another page with duplicate content, or show an error. So, yeah, my advice is to do page recursion on at least most of your form posting, but do it tactfully, keeping in mind that you will have programmers one day who inherit your code. So make good use of comments, and make the if/then logic clear such as:

if ($bFormPosted) {

or at least:

if ($_POST) {

Well, gotta run. Hope this helps!

Yet Another ORM Tool

If you're looking for yet another ORM tool, here's one that might knock your socks off. It's called Outlet and it's SUPER EASY!!!

http://outlet.knowledgehead.com/wiki/index.php/Main_Page

The advantage of this system is that you build an object class that describes your content with private vars and set/get methods, and then run it through Outlet to drive your ORM automatically. If you have special SELECT needs, it can do that too.

It's written for PDO and has been tested with SQLite and MySQL 5.

Here's a Quick Start that makes it very apparent to you how easy this thing is.

http://outlet.knowledgehead.com/wiki/index.php/Quick_Start_Guide