In this new post to the PHPWomen site, Kim Rowan shows one way that you can effectively handle concurrency in your applications (in her case, a Symfony app).

Concurrent user activity on the web can take many forms. For example, two online shoppers may simultaneously try to buy the last pair of ‘gotta-have-em’ shoes in stock. Presumably one potential outcome in this scenario is to place the shoes on back-order for the slower shopper. The concurrency challenge I faced recently, however, was a bit different...

She uses a "last updated" data field in her form to see when the record in question was last changed. When the form is submitted the script checks against the updated date on the record to see if it's later than the one submitted. If it's more recent, the user's request could cause errors, so it fails.

In this new post to DZone.com Giorgio Sironi looks at a method for "recording" the request and response information for an application that might be lacking in documentation using PHP's output buffering.

So you've got this big ball of code. You don't even know how to call all of these scripts, but the code is in production and works just fine (until you have to change even a single line). How to define some characterization tests that describe how the .php scripts work now? [...] If tests do not exist, we do not know if they expect GET or POST requests, which parameters they contain, and above all what their response should be in correct and error cases. Even if all the links and calling code are under your control, it may be faster to go for the recording approach. If other applications and machines call your .php files, it is your only choice.

He suggests using ob_start and the output buffering methods to handle the recording as it lets us define a callback (or in his case, a recording object). He includes an abstract version of it, showing how to implement a "Tape" class and a "record" method to handle the data and push it into a log or some other recording mechanism.

Dan Scott has posted an example of how to create a MARC record (machine-readable cataloging, more details here) from scratch with the help of the File_MARC PEAR package.

In the past couple of days, two people have written me email essentially saying: "Dan, this File_MARC library sounds great - but I can't figure out how to create a record from scratch with it! Can you please help me? Yes, when you're dealing with MARC, you'll quickly get all weepy and get help from anyone you can.

His example code is pretty simple - load the PEAR package into the script, create the record object and start adding fields to it. He shows various output methods ("pretty print", writing the raw data to a file, etc.) and the output to various other data structures like JSON and XML.

Adam Jensen has written up a quick tutorial about using Doctrine record listeners to link a Zend_Acl component with your database.

In previous Zend Framework apps I've written, I often handled access control at the level of the controller action. Each action was represented in the ACL as a resource, and the ACL logic was applied by a custom plugin just prior to any action dispatch. [...] As a result of these concerns, I decided on a lower-level, model-centric approach for this blog: my models are my resources. Each model class implements Zend_Acl_Resource_Interface, and the ACL specifies "create," "read," "update" and "destroy" privileges for each class (more or less).

Checking for the permissions with a setup like this can be time consuming, though, so he found an ally in the record listeners Doctrine allows you to set. He combines a Doctrine_Record_Listener object with a Zend_Acl one in a preInsert method with a getCurrentRole to add the user handling all in one place.

In the third part of the series dealing with using Doctrine in your PHP applications, ProDevTips has this third part looking at a method for extending the tool's current functionality.

I simply knew we would need the extension capability that the Mdl class allows for sooner or later, I didn’t expect it to be this soon though. The main problem here is saving a many to many relationship straight to the database from the $_POST array, to do that we can extend Doctrine Record with a new function I have named fromArrayExt which adds something extra to the normal fromArray method.

He shows how to extend the classes to create custom handlers for a grouping of checkboxes. The new code automatically handles their submitted values and pushes them directly into the database (with a simple save() call).

DynamicWebPages.de has posted their new statistics for PHP usage in the community for this past month:

After the small decrease in the last month, PHP made it back up easily. For the first time since April 2006, the 20 million mark on the number of domains has been passed. In contrast to the previous month that means a jump of nearly 800,000 domains. The number of IP addresses, on which PHP is installed, also has numbers worth checking out. With 1,332,514 IP addresses on record, this month's numbers are the highest conditions since September 2004.

You can check out the graph and the statistics for the last year in their statistics page of their site.

DynamicWebPages.de has posted their new statistics for PHP usage in the community for this past month:

After the small decrease in the last month, PHP made it back up easily. For the first time since April 2006, the 20 million mark on the number of domains has been passed. In contrast to the previous month that means a jump of nearly 800,000 domains. The number of IP addresses, on which PHP is installed, also has numbers worth checking out. With 1,332,514 IP addresses on record, this month's numbers are the highest conditions since September 2004.

You can check out the graph and the statistics for the last year in their statistics page of their site.

On The Bakery, there's a new expanded tutorial (from this) that talks about how to check for duplicate records in your CakePHP model.

[Here's how to] validate a form field (such as a user name field), both in add and edit form and make sure that the selected user name does not already exist in the database [via a] function repeated only once (in app/app_model.php).

The example model they give defines an isUnique method that essentially runs an automatic check (a count() call) on the table to see if the given information exists. The example Model, View, and Controller are all given.

On The Bakery, there's a new expanded tutorial (from this) that talks about how to check for duplicate records in your CakePHP model.

[Here's how to] validate a form field (such as a user name field), both in add and edit form and make sure that the selected user name does not already exist in the database [via a] function repeated only once (in app/app_model.php).

The example model they give defines an isUnique method that essentially runs an automatic check (a count() call) on the table to see if the given information exists. The example Model, View, and Controller are all given.

From the Inside Open Source blog (from APress) there comes a helpful tip for those working with Firefox and PHPMyAdmin on a lower resolution screen:

I'm currently working on an e-commerce project involving a relatively small number of database tables. However the clients table consists of 19 fields, making for difficult data review and debugging within PHPMyAdmin, even at 1280×768 resolution.

The answer is simple, at least if you're using Firefox. Firefox offers three hotkeys for changing the text size, and resultingly, the amount of text you can see on one screen.

The keys for this easy little fix use the Control key and plus (larger), minus (smaller), and zero (return to default size).