debuggable

Hey folks,

sorry about the long delay. But CakePHP 1.2 RC1 is out and as sweet as it can be. Quick facts:

• 800++ commits
• 100++ bug fixes
• tons of security and feature additions

Read all the facts in the 1.2 RC1 release announcement or download your fresh cake right away. To get an idea what all was changed, have a look at changelog here.

Thanks to everybody for contributed patches, tests, tickets, money, love, help and happiness!

-- Felix Geisendörfer aka the_undefined

Hey folks (I guess I should maintain the traditional introduction),

As you may know, I don't blog very regularly. This is mainly due to the fact that I have my own custom-built blog (that was written forever ago) and I'm just too lazy to maintain it (the code, that is). At this point, most of what I wrote I either don't like, or is too outdated, or should really be folded into the Cookbook.

So, I asked my good friends Tim and Felix to be my blogging label. Similar to how a record label works, I'll do all the work and they'll get all the money. I'll also ride around in a tour bus for weeks on end without showering. So debuggable.com will now be the home of all my CakePHP news and tips that don't show up on the Bakery.

So thanks Tim and Felix for hosting me, and thank you all for reading. I have a couple ideas on different series' of topics to write about, but if you have some ideas, you can comment or email me.

See y'all around.

Hey folks (what the heck, do we always start our posts with that phrase?),

Yeah so the new code coverage in the cake core is also capable of tracking the amount of code lines covered in each test case file when running a group test. Just form your groups, hop into the testsuite, run the group and then run the code coverage analyzation.

Here is an example output for one of the core groups:

I did not put this in the first post about Code Coverage Analysis in CakePHP, because this was an enhancement committed a few days after the initial code coverage implementation.

Hey folks,

lets say you have a model called Upload. Your Upload model has some generic fields like this:

The problem

However, you would like to store different types of meta information for different kinds of uploads. Examples:

Images:

• Width
• Height
• Quality (if jpg)
• Camera
• Lens
• Focus

Videos:

• FPS
• Bitrate

PDFs:

• Author
• Description

ZIPs:

• Original Size
• File Count
• Compression Rate

The solution

So what are you going to do? Add 13 fields to your uploads table? Probably not. It is time to normalize things:

Ok nothing fancy so far. CakePHP's associations make it easy to deal with it. However, working with this setup can be a little inconvenient at times. Everytime you fetch a set of records from Upload, you will have to manually extract the meta information from the associated UploadField records:

-
    Upload:
        id: 1
        name: funny.mov
        type: video/quicktime
        bytes: 20480
        created: 2008-06-01 14:47:23
    UploadField:
        -
            id: 1
            upload_id: 1
            key: fps
            val: 26
        -
            id: 2
            upload_id: 1
            key: bitrate
            val: 376

So everytime you want to access your videos bitrate you will have to search your UploadField records for the 'bitrate' key. How annoying. But worry not, Expandable comes to rescue. With the Expandable behavior activated on your Upload model, your resultset will look like this:

-
    Upload:
        id: 1
        name: funny.mov
        type: video/quicktime
        bytes: 20480
        created: 2008-06-01 14:47:23
        fps: 26
        bitrate: 376
    UploadField:
        -
            id: 1
            upload_id: 1
            key: fps
            val: 26
        -
            id: 2
            upload_id: 1
            key: bitrate
            val: 376

But it comes even better. Expandable also makes it dead-simple to create / update UploadField records. This is how it works:

Without you having to do anything, the following happens to your uploads resultset:

-
    Upload:
        id: 1
        name: funny.mov
        type: video/quicktime
        bytes: 20480
        created: 2008-06-01 14:47:23
        fps: 30
        bitrate: 376
        rating: 0.7
    UploadField:
        -
            id: 1
            upload_id: 1
            key: fps
            val: 30
        -
            id: 2
            upload_id: 1
            key: bitrate
            val: 376
        -
            id: 3
            upload_id: 1
            key: rating
            val: 0.7

As you can see the fps UploadField value has been updated and a new record with the key rating has been created. So this means you can use the CakePHP form helper to create different editors for your uploads like this:

And even so none of those fields really exist on the Upload model, everything will work just as if they would ; ).

How to use it

1. Download the behavior from: the debuggable Scraps repository at github
2. Place the expandable.php file into /app/models/behaviors/expandable.php
3. Optional: Place the expandable.test.php file into /app/tests/cases/behaviors/expandable.test.php
4. Create a table and model for UploadField with at least the fields shown above. (replace Upload with the name of your base model)
5. Setup a Upload hasMany UploadField and UploadField belongsTo Upload association
6. Add this to your Upload model:

That is it. You are ready to go. Enjoy the magic ; ).

Pro	Contra
Easy to use Saves db space Mostly leverages existing CakePHP magic	(Small) Performance hit while updating meta data

Please let me know what you think about this approach!

-- Felix Geisendörfer aka the_undefined

Okay, some of you guys who followed Felix' Blog thinkingphp.org back two years ago might remember the post where he put his face into a cake because he failed to keep an important promise.

Well I don't even have to promise you anything to make a fool out of myself. I am just purely destructive... and deleted the cake folder from the cake branch today. Let me explain...

So this is how it happened: I worked on another project and was writing a blogpost of some new feature in cake. Then I set up some example code to explain the new way things work. As it turned out, the project had an SVN HEAD checkout from the cake core for no apparent reason. I normally just use the 6311 release for projects I work on alone and be fine with it. This is mostly because of requests of clients. Please do not ask why this was an SVN HEAD checkout... I have no idea whatsoever, but probably it was a relict from the past.

So, I happily svn removed the cake folder in order to get a copy of the cake core. :O I thought, well since we are at a release-near state, I can get a svn export'ed cake core and then svn add'ed it to the project. So with the cake core removed, I committed. Since it was a reference to the branch on the cake project, I deleted the entire cake folder in the cake branch..

So I wanted to do the svn checkout now and svn told me the url doesn't exist. Hrm? https://svn.cakephp.org/repo/trunk/cake/1.2.x.x/cake/ does not exist? Dear SVN would you please not mess with me? I went to the cake revlog and saw something that totally shocked me:

@7061 [7061] 05/30/08 05:59:16 DarkAngelBGE deleting cake folder from svn

Oh what the heck!! Yeah, so being totally unable to touch any keyboard I asked nate to help me restore it, which he did. Thanks a lot nate.

So that's about it. Totally lame, but fixed immediately without the statistics being nuked. Thank god for SVN, and some of the better alternatives.

Felix and I already thought of a couple of ways in order to humiliate me in public, like he did back with the cake-in-his-face post. We have some cool ideas, but please shoot some if you think of cool ones. Our favorite one for now is getting me buried in sand and then getting whipped cream painted all over the face to look like a cake.

So in case you have already noticed my accident, I just wanted to show the community the cake team is honest and owes up to their mistakes. Let's take it like men.

-- embarrased Tim Koschuetzki aka DarkAngelBGE