Continuing on from the first part of their tutorial series about creating a simple ad tracker for your web application, Developer Drive is back with part two, a more in-depth look at the actual object design and code.

In our last PHP Ad Tracker lesson, we constructed the database tables for our ad banner application. Now we are ready to construct the data object that will hold the variables and functions that will display, add, edit and delete the data in those tables.

They cover each of the variables they'll be using with a summary of what they're used for as well as the various functions to be defined and what they'll return. Following this, they get into the actual development - creating an "ads" class and defining the methods to get the current ad count, get the number of clients and pull the actual client/ad data.

On the Refulz.com blog there's a new post looking at some of the new features in CakePHP 2.0 including its use of lazy loading, the CakeEmail library and the new class loader.

With CakePHP 2.0, they have dropped support for PHP 4 and have refactored the library code to make it strictly complaint with PHP 5.2+. Modeled on Ruby on Rails (RoR), CakePHP is a tough competition to Zend framework, Symfony and CodeIgniter.

Besides the topics mentioned above, he also goes into the details of the new CakeRequest and CakeResponse models (to access information about teh current request/response). Summaries of all of the new functionality are provided along with some sample code where needed to illustrate.

Following up from his (now infamous) MicroPHP manifesto, Ed Finkler has this new post to his blog answering some of the common questions he's gotten about his beliefs.

My previous post, The MicroPHP Manifesto, resulted in much excitement. In between fits of rage and crying, I found some time to answer folks questions, and also discuss the topic on the /dev/hell podcast with my cohost Chris Hartjes. To summarize and address some of the common questions, I felt I should write a small FAQ.

Questions asked so far include:

• So you think full-stack frameworks suck?
• You need a large framework to enforce best practices!
• You should check out my microframework!
• How do you choose what gets listed in the MicroPHP code collection?
• Why do you hate Rush?

If you have a question you don't see listed, drop him a note and he'll add to the post with more answers.

Rob Allen has a tip for the Zend Framework users out there using the Zend_Db module to connect to their database resources - how to do a one to many join with the help of Zend_Db_Table_Select (easier than it sounds).

Let's say that you want to set up a one-to-many relationship between two tables: Artists and Albums because you've refactored my ZF1 tutorial. [...] Assuming you're using Zend_Db_Table, the easiest way is to turn off the integrity check and do a join in a mapper or table method.

He includes a few lines of source to illustrate, calling the "setIntegrityCheck" value to "false" to tell ZF not to worry about the additional join value over to the artists table. The result is a new column value with the artist's name instead of just the ID.

In a recent post to his blog, Gonzalo Ayuso shares a few tips on preventing SQL injection attacks on your applications.

Security is a part of our work as developers. We need to ensure our applications against malicious attacks. SQL Injection is one of the most common possible attacks. Basically SQL Injection is one kind of attack that happens when someone injects SQL statements in our application. You can find a lot of info about SQL Injection attack. Basically you need to follow the security golden rule: "Filter input, Escape output".

He advocates the use of the PDO abstraction layer to filter out a lot of the issues. Using its prepared statements, you can easily strip out things that just adding slashes to user input wouldn't prevent. He also includes a reminder about database permissions - allowing only certain users the ability to, for example, delete can help provide one more level of security (in other words, don't use a "super user" in production).

• Secure Get
• Data URI
• ApPHP Data Grid
• ApPHP Data Form
• URI Rewrite Handler
• PHP Image Class
• SQL Object
• ApPHP Tabs
• Fast DB Class Generator

Kurt Payne has a new post to his blog showing how to use register_tick_function with a callback to help benchmark and profile your application to find its pain spots.

A profiler gives you the ability to trace the performance of your code through every function call and create an overview of your system's performance over a certain time period and helps you make intelligent decisions about where to look for problems. [...] But what if you're in an environment where you can't install [the xdebug or xhprof] extension? Luckily, php has a built-in function called register_tick_function that gives you a way to hook in to every user function that's called. With this, you can write a profiler yourself.

A bit of sample code illustrates his method - it defines a "do_profile" function and assigns it with the register_tick_function call. This function generates a debug backtrace and echos out the function path it took to get to that spot (output is included). He provides code for a bit more useful profiling and points out that it could easily be graphed to help visualize the problems. Also included are a few caveats to watch out for when using this method of profiling.

In this recent post to his blog, Chris Hartjes answers his request for a "rant topic" by responding to a question about "how to not suck at PHP" (from Travis Northcutt).

I thought about this question for a while and have some thoughts on what it really means to know how to not suck at building things using PHP. In my never even remotely humble opinion I think the key is to understand what PHP is really good at.

He talks about how PHP had the early-adoption advantage at first with Apache, but how things have changed so much since then. Now, he proposes, PHP's popularity and usefulness is based on what it can do as a language without messing with frameworks at all. He's worried that, once someone picks up a framework, it'll become so ingrained that they won't know what "plain old PHP" can do (or how to work with it).

So my advice to Travis is that he should worry about learning to use PHP like glue and correctly identify the problems he is trying to solve NOW instead of worrying about the problems he might have to solve later. There will be time to fix your problems. Some of those will be solved by using tools that are not written in PHP, but PHP can still glue them together.

Following up on their previous look at the component architecture of the Yii framework, PHPMaster has posted this new tutorial showing how the framework allows you to do some event-based programming.

An application event is something that occurs which might be of interest to other bits of code. A standard event in most GUI applications would be a "click" event, but the sky's the limit and what events you define is really up to you. [...] The details can be provided by application-specific modules allowing you to keep individual requirements separate from your reusable code. Events allow you to attach a potentially unlimited amount of functionality without changing your core modules and components.

In his example, he shows how to create an event handler that is triggered when the user registers on the site. This event (CEvent) is then registered with the system and is attached via a call in the controller's "init" method.

On the NetTuts.com site there's a new tutorial showing you how to introduce the Memcached tool to your application - a quick and easy way to cache data and optimize performance.

Your latest PHP/MySQL website is finally online. And it's awesome. But it's not as fast as you want it to be, because of the many SQL queries running every time a page is generated. And above that, you have the feeling it will not scale well under heavy loads. And you are most likely right. In this tutorial, we will see how you can greatly improve your website's responsiveness [...] by implementing a cache layer between your code and your database. The good news is it is fairly easy, and can be done in a few minutes!

They help you get the memcached server installed (a one-liner in most linux distributions) and how to install the memcached extension using PECL. Code is included showing you how to connect to the server, store data into the cache based on a generated key and how to pull the same data back out.