Symfony users will want to check out this pre-commit hook for git from Graham Christensen that can help you keep your sanity in place by rebuilding some of the essentials when a commit is made.

Throughout my history of working with Symfony, I've noticed a trend that I'll make a minor edit in a database configuration file, forget to actually regenerate the models and forms, commit the edit, and then find several days later (when I do want to regenerate the models) that they're breaking. I then do this little dance of going through the history finding out where exactly I went wrong.

To remedy the situation he came up with a pre-commit hook that does the following:

• rebuilds SQL from schemas
• rebuilds models
• rebuilds forms
• rebuilds filters
• inserts sample SQL data
• loads all data from the fixture files

Full example code for the hook is included in the post.

Rob Allen has posted this look at using hooks inside of action helpers (a follow-up from his previous article on action helpers):

Hooks are a feature of action helpers that allow you to automatically run code at certain points in the dispatch cycle. Specially, there are two hook functions available for action helpers: preDispatch and postDispatch. These allow you to ensure that some functionality is always run for each request.

He creates a simple action helper that grabs a random quote from an array and drops it into a property of the helper. By defining a preDispatch method inside of the helper, the HelperBroker knows to pull the method in an execute it immediate before the rest of the actions are executed. A calls to addHelper with the hooks defined is all it takes to glue it together with the execution.

On the SaniSoft blog Tarique Sani has posted about (and made available for download) some code sniffs for the CakePHP framework. Some problems arose with some of the naming that the framework uses, but with some "tinkering around"...

[It became] apparent that I had to have my own set of Cake sniffs to manage this but a separate standard just for this seemed an over kill and the simplicity of code made it kind of fun to add more standards which I liked but were in different set of sniffs.

You can grab the whole list of sniffs from their downloads. They implemented them as a pre-commit hook on their SVN server even so that developers could not violate the coding standards when they submit their code.

On the Zend Developer Zone, there's a new article that examines one of the key components to just about any framework out there - the front controller.

Like Action Helpers, which I've discussed in a previous article, Front Controller Plugins in Zend Framework are often considered an esoteric, advanced subject. They are, however, remarkably simple to implement, and provide an easy way to extend the functionality and behavior of your entire web application.

The article (from Matthew Weir O'Phinney) looks at the hooks defined in the controller, like routeStartup and preDispatch, and how to work with the controller to add in/get plugins from it. He provides a two examples too: Application Initialization Plugin and a Caching Plugin.

In a continuation of their series looking at what's new in PHP5, the IBM developerWorks site has posted part five, a look at the handy addition of the file upload progress functionality.

Given that uploading huge files can be tedious for impatient users, it is important to provide them positive feedback to keep them from giving up and going away.

Fortunately, PHP V5.2's new hooks into the file upload process allow us to show users in real time what is happening with their uploads. In this article, we will create a progress bar using PHP V5.2 for our users (see Download for source code).

They talk about what "hooks" are to explain how things work together before getting into the setup of the sample app. They chose to go with WAMP for their examples, but it can be easily adapted to any other flavor of *AMP setup of your choosing.

They set up a default upload box inside of a normal form the user can upload a file with. The real magic happens on the backend when the "Upload" button is hit. Via a handy call to the apc_fetch function, we can determine how far along the file is in the upload. This is relayed back to the script when their "Start me up!" link is clicked and a progress bar is advanced as the file is uploaded.

On Dotvoid.com, there's a new post that reminds us of two of the more "ajaxified" features of the new releases of PHP 5 (like 5.2) - the JSON extension and the functionality to track file uploads.

These features aren't competing for the heavy weight title in the release notes. Still, having these implemented in PHP makes it a lot easier to develop modern, more responsive, web based applications.

You can get more info on the JSON extension here and an example of the file upload monitor in this entry on the Bitflux blog.

CakePHP users out there looking to squeeze just a bit more out of their plugins might want to check out this new post over on Felix Geisendörfer's blog today. He shows how he's worked around two issues that have bothered him with the current framework setup - inter-plugin communication and filter callbacks.

He starts off by looking at the filter callbacks, looking to make "drag and drop-able" plugins for his setup. He notes that, right now, you'd have to call a plugin to perfom an action, making for a good bit of load depending on the application structure. It also means that you have to change the Controller to add a new plugin ("...which doesn't seem like a very RAD approach to me").

So in order to streamline such plugin callbacks, I created a function inside SpliceIt!, that allows plugins to hook into any AppController event, such as beforeFilter, afterFilter, beforeRender, etc. in order to make their own changes to the controller. So a Themes plugin can easily change the Controller::view and a Statistics plugin can make calls to a Model.

He gives the code for the function as well as an example of how to use it in your app.

Moving on, he looks at his next issue to overcome - inter-plugin communication:

Generally spoken Controller::requestAction() isn't a bad way to exchange data between controllers. It's a clean interface and you don't have to plan in advance what data should be exchangeable and what data should not. However, there are a couple problems with it.

His solution involves the creation of an entirely seperate ApiController pattern. Of course, he provides examples, specifically related to his SpliceIt! application.

Content no longer valid