nabeel shahzad

CakePHP 2.1+ (currently in beta) comes with an awesome new feature called view blocks and view extensions (official docs here). This allows you to modify views, append to them, and change them, based on the content that might come later on in your code.

Previously, for building a breadcrumb, there was a giant if/else tree for parsing the request object, and views and helpers all structured to allow for the flexibility. In short, a nightmare. Now with view blocks functionality, it reduces it down to a very simple set of elements, which can be called in meaningful views.

View blocks are built as, you guessed it, blocks. Each block has a name (you chose it, whatever is relevant, “sidebar”, “breadcrumb”). You define a block as such:

Where do you place this? In a view file. For example, when a user goes to mysite.com/listings/add, it loads a view in Listings/add.ctp. Inside this file, at the top, you do can do:

This says that when this view (Listings/add.ctp) is loaded, then the breadcrumb should be “Home > Add Listing”. Of course this is simplified (I removed any HTML, etc, just to demonstrate).

Now that we have one view block, we need to pull this into the main layout. Since the breadcrumb shows up before any content, we will structure it using an element, which is pulled into the default layout file. I have an element, in Elements/breadcrumbs/base.ctp, which houses the basic structure of my breadcrumb. This element is called from my Layouts/default.ctp (also, super simplified):

The $this->fetch(‘breadcrumb’) is getting a block by the name of breadcrumb. I check to see if that block exists; if it doesn’t, then I output a default item of “Home”. Otherwise, I output the contents of the “breadcrumb” block.

Then when you load the page, it will show Home, and if you go to Listings/add, it will show Home > Add. Pretty simple! In my views, instead of calling the start()/end(), I have an element, under Elements/breadcrumbs/single.ctp, that builds a single level breadcrumb:

You can clean this up even more by automating it from the $this->request, and using $title_for_layout. I also have another view, which takes an array as a parameter, to build multi-level breadcrumbs:

Hope this helps! The $scripts_for_layout has also been deprecated in favor of of the view-blocks feature, which create, since now Javascript file can be included on a page-by-page basis, using $this->append

I put a list together for a friend of some good PHP resources, thought I’d stick it up here as well:

Of course, the best resource, the official docs:
http://www.php.net

Another great (official) place:
http://talks.php.net/

The talks are by the creators of PHP. Any talks by Rasmus Lerfdorf are excellent, he stresses simplicity over complexity. He’s also the creator of PHP. Derick Rethans is also an excellent presenter, he focuses a lot on security and debugging. Definitely watch the presentations in the “Security” section of the talks, but overall, any talk in there has information you can use to your advantage.

Other sites:
http://www.smashingmagazine.com/2009/03/24/10-useful-php-tips-revisited/
http://php.about.com/od/advancedphp/Advanced_PHP.htm

Sitepoint is where I first started learning HTML and CSS many years ago:
http://www.sitepoint.com/subcat/php-tutorials

MVC tutorials (how apps should be coded; obviously there’s some contention between OO and procedural styles, but you need knowledge of both to be able to make an educated judgment about what a good balance between the two is)
http://www.phpro.org/tutorials/Model-View-Controller-MVC.html
Good to go through to understand MVC completely

CakePHP has a good introduction:
http://book.cakephp.org/view/10/Understanding-Model-View-Controller

Which brings me to CakePHP itself. It’s an excellent MVC framework; after trying out CodeIgniter, Zend, Yii, Kohana, I’ve settled on Cake.
http://cakephp.org/

SQL resources – the best is the manual. Learning the concepts behind joins is essential and important. A good tutorial:
http://www.codinghorror.com/blog/archives/000976.html

Also database design:
http://www.simple-talk.com/sql/database-administration/ten-common-database-design-mistakes/
http://woork.blogspot.com/2008/09/10-useful-articles-about-database.html

Following that up are good ORM, which you may want to use as your database layer. CakePHP has ORM built-in, but sometimes all you need is just a DB layer.
http://www.doctrine-project.org/

For conventions, I tend to follow the CakePHP model (since that’s the framework I use the most):
http://book.cakephp.org/view/24/Model-and-Database-Conventions
http://bakery.cakephp.org/articles/view/database-design-and-cakephp
http://book.cakephp.org/view/22/CakePHP-Conventions

And then rounding it out, some general knowledge information:
http://articles.sitepoint.com/category/html
http://articles.sitepoint.com/category/javascript
http://articles.sitepoint.com/category/cssh
http://www.jquery.com

This one took me a few to figure out. On VACentral, there are schedules, which have an arrival and departure point. These points are all stored in one table, so one row in schedule refers to multiple entries in the airports table. It looks something like (ok, not something like, but exactly):

So two ICAO columns in routes map to one same column in airports. The ICAO is a unique 4 character identifier, which is assigned to an airport. It’s quite simple actually, but took me a while to figure it it. First the Airports model:

And then our Schedules model:

So we used the $belongTo relationship, and we will define two relationships – “DepartureAirport” and “ArrivalAirport”. We also select the class we will use (which IMO, should really be called “modelName” or “useModel”, that really tripped me up, but I digress). Next, we define the conditions – we’ll use the relationship name (DepartureAirport or ArrivalAirport), and the column name, along with the column name on the current table it should join on. And that’s pretty much it. You don’t really need a relationship on the “receiving” end (the Airports table), unless you will be querying airports, and finding out what schedules go there. I’ll leave that upto you

And then for the query itself:

Which will now return something like (etc fields ommitted):

Note how it’s using the Containable behavior; this is so it doesn’t pull every relationship you’ve defined with that table (the schedules table above has many more relationships, but for brevity, I only pulled the relevant ones). Not specifying Containable() is REALLY expensive, especially when you don’t need all those relationships to be included in every time! To speed it up even more, you should specify the actual field names to pull (the SQL * operator is expensive).

As-per Justin’s request, I’ve renamed by fork of ezSQL to ezDB. I’ve updated the github links, it’s now:

http://github.com/nshahzad/ezdb/

This will include changes to the class names, to keep it all even (ezSQL to ezDB). I’m working on APC caching right now, since that’s what I’m using on current project.

PHP 5.3 was also released today! This is an exciting release – with the addition of namespaces and __callStatic(), the static DB class will be much easier to work with (instead of replicating every function). I will be finishing up the 5.2 release first, and then subsequent releases and features, I think I will be posting to the PHP 5.3 release only, unless there’s demand to back-port it all.

I’ll also be implementing some features from CakePHP’s ORM, such as “findBy{ColumnName}({tablename})”, and other simple lookups. I’ve been using Cake alot too, and it’s a great framework.
Cheers!

This weekend, I started my server migration, over to Slicehost. It went well, now I’m running on a lean ‘n mean nginx install. As I was moving my Subversion repositories, I was dreading having to move all my shell scripts, which I used to build and deploy some of my applications (outlined in this post). I was thinking there had to be a better way, after all, Ruby has Capistrano, and though it can be used with PHP, I didn’t want to have to install Ruby, etc etc. After some searching (not much), I found Phing, which looked like exactly what I needed. Sweet!

Phing takes an XML file, which you can define all the transformations and instructions. It has sets called “targets”, which are different stages of the build and transformation. They have a basic example here, but I’ll go through my phpVMS build.xml, since I do a number of things they don’t show in the examples, like checking out from Subversion, some variable replacements, and building tars for different “stages”. Having targets was great, since you can select which targets to run, so now I can combine a “beta” and “release” builder, instead of having separate files for it (as I did with the shell scripts). My goals are the same as in the SSH scripts:

• Automatically build beta, full, and update versions from SVN
• Update revision numbers within several files using tokens or regex
• Copy it to the test site
• Automatically generate PHPDoc API documentation

Phing is perfect for this. I had sets of painful-to-maintain and update SSH scripts to do this same thing. And it has a simple PEAR installer. I installed it using:

]

And that was it! Installed. They do have instructions for a I now had “phing” available on the command line:

]

Now we can get started, building our XML file. The file starts with:

That’s our basic container; as you can see I set the project name, the default “target” or stage to run, and the base directory.  Everything we do/add will go inside the project tags.

Now, I’m going to add some common “properties”, or variables, that will be used throughout the script, to make it easier, and not have to type out paths over and over:

Use absolute paths if you can, otherwise, it’s relative to the basedir property defined in the project tag.

The reason for having a working copy and an export directory for SVN is this – the checkout directory will be used to determine the latest revision, since the svnlastrevision command requires the path to a working copy. The export directory is to hold a clean export; without all the subversion specific data that’s included in a checkout. We’ll package that up, and use that to copy to a test site.

Next, I define the targets, or stages, I’m going to use: prepare, build, subs, phpdoc, beta, and release.  They are setup this way in roughly the order they will run. The order doesn’t matter, since we determine the order of the targets by using the “depends” property. I’ll explain each one in detail:

So now that we have an outline, we can go through each target, doing what we need to do, first our “prepare” stage:

We’re using our properties which we defined, as ${propertyname}. Don’t need to do any escaping, etc, just use ‘em right in the strings.

Next is our build target stage, which will do the Subversion operations of getting the latest revision.

It’s great how Subversion operations can easily be done. Next target is subs, to replace any tokens and variables we define in the files.

Next is our phpDoc function, which is sort of standalone, in the fact that there are no depends for it.

Now that we’ve got the basics down, the next two targets are “beta” and “release”. Each of these handles a different set of tasks, though they are basically the same. First for beta:

And now for the release target. Release a bit different than beta – it creates two different archives – one full version, and one update. The difference essentially is that the update copy has the local configuration file removed, where database settings are stored, and other settings which are kept locally.

And that’s it! Now we can run it using:

]

Using the appropriate one we want to use. In my SVN post-commit file, I run the beta line, in order to have that build every time.

I attached a fully doc’d version here (same as the above, just in one file). I hope it helps!

Note: I’ve made a dedicated page for ezSQL-related items, you can view it here

I’ve been using ezSQL for a long time, as my “database driver”. It’s an awesome little class, that you can easily use to get database results, and return in different formats. I’ve made a bunch of changes and updates to it, so I thought I’d put them out there and share them.

Along the way, I’ve made some updates and changes to it, to suite my requirements, including format PHP5 support. I’ve updated the error handling/logging, so now you can call:

Respectively after queries to return the “real” status of a query. the debug() function has been added to, so at call time, you can pass to bool whether to display the result on the screen, or pass it back as a string

I’ve also added several utility functions:

To make it easier to do simple SELECT’s and UPDATEs, and INSERTs.

Another thing it was missing with MySQLi support, so that has been added (though I have not had the time to add support for statements (though that can be accessed rather easily). I had added MSSQL support, but the file has gone AWOL (Icreated and used it for a specific project a while ago). I will update when I get a hold of it.

And another thing I added was a static interface class, which I use all the time on PHP5 projects:

Makes it much easier to access the database function, without having to do $db = DB::getInstance(), in every single function to get a singleton object of the database. Since that’s for PHP5 only, the whole library has been updated for PHP 5 support, with public/private functions and constructors/destructors as well.

I also condensed it to just one include() now, just keep all the files in the same place (include ‘…/DB.class.php’). From that you can either use the static class, or declare a new ezSQL object.

I also added in phpDoc blocks on all the functions, since IntelliSense is awesome and really helpful.

I hope these improvements make it easier for everyone. Of course, the original credit goes to Justin Vincent. There are some docs and examples here as well.

You can download it from here

I put out the update for 1.1.400 (version bump, went from 1.0 to 1.1 because of “major” features), then the 400 being the revision number from SVN. So far no problems, my main concern were the tons of database changes, including the removal of foreign keys, which made me a bit nervous, since I guess different versions react differently.

Instead of doing scratch installs, and then doing an update (time consuming), I wrote a quick SQL file, and another bash script which would automatically insert the older 1.0 database (basically running the install.sql), and then run the update.sql, and report any errors which are thrown:

The line to drop all the tables was from this page here (thanks!). My install.sql can also include the SQL inserts for default values (I will post the code for my installer soon, since it’ll just read any .sql file), but what I will do is create a backup of an existing DB with all my data, and run the update against that using this script.

Pretty basic, but really handy to just viewing errors.