In many instances, having a plugin system (even for closed-source applications) is a convenient and safe approach to adding functionality to a product. It minimizes risk by not having to modify the core of the source. In this article, I'll be discussing how we implemented a plugin system for our cart software to allow for plugins.

Its implemented a bit like the Observer design pattern - you "register" the listening event which can then be activated by a "trigger" method with the event's name. These events are stored in a registry (static) so they can be accessed across the application.

During the recent development of the new PHP cloud development casts site, which has been developed with the Zend Framework, so much development time has been saved by using one of the simplest and arguably best features of the framework: Controller Plugins. So today I want to introduce you to them and walk you through a working plugin so you can see just how effective and efficient they can make your development workflow.

He starts with a look at the events that fire in the process of plugin execution (including "routeStartup" and "preDispatch") and as well as some common uses like inserting code at the end of a request automatically or redirecting a user if they're not logged in. Included in the post is a simple code example showing the setup of a simple plugin that redirects the user to the "/index/index" path if they're not already there.

Both the Module Manager and the MVC system use the Event Manger extensively in order to provide "hook points" for you to add your own code into the application flow. This is a list of the events triggered by each class during a standard request with the Skeleton Application.

It's broken up into the three main chunks - Module Manager, Bootstrap and Application - with any sub-requests and their sources (like "render", "dispatch" or "response"). You can find out more about ZF2's Event Manager in other posts like this one from Kevin Schroeder or this from Matthew Weier O'Phinney.

We're well into 2011, and many designers and developers around the world are planning their travels for the year, including the possibility of attending any Web design or development conferences. To help you out with your plans for the upcoming months, we've put together a list of conferences and events that you might want to consider. This particular post covers events taking place in about a six month timeframe that ends in late August and early September.

Their list includes PHP-related events such as the International PHP Conference and events surrounding many other technologies like Ruby, Photoshop, MySQL, Javascript and lots of other more business-minded sort of events. Check out their full list to see which ones you might want to attend.

In my previous article I summarized event system definitions and showed an example of PHP event model, which is built with the call_user_func() function. This acticle expands the subject by introducing an advanced PHP event model that is based on sender/eventObject/listener collaboration, which was popularized by the Java world.

He steps through some examples with ProtocolCommandSupport.java and ProtocolCommandListener.java functionality, showing how to take that functionality back over to PHP and implement it using the built-in features.

Some of the topics touched on this week include:

• the "Five Best Next Generation PHP Frameworks" article
• "The Evolution of PHP on the Internet" - Nexen.net's latest stats
• comparing mod_php and FastCGI
• the announcement of "Baking Day" from the CakePHP group
• and several of the new PEAR/PECL/Zend Framework updates from the week

Of course, this list only touches briefly on all of the happenings this week, so check out the full list on their site.

PHP has the drawback of not supporting events. Fortunately, a basic structure can be built to support events in PHP 5. This article tackles that problem with some proof of concept code.

It seemed reasonable to me that some sort of basic structure could be established to support events in PHP 5, so I set out to whip something up as quickly as possible as a proof of concept. The contents of this article are the work of roughly one programming hour and surely stand to be improved upon, but the basic idea is this: instantiate an object and attach event handlers; the handlers will be executed when the events they are associated with are raised.

They look first at how to create a simple object to store the information in and a "collection" class to manage those objects. They move on to the creation of the event handler class and a "collection" class for handling those as well. Finally, they get to the combination of the above items - a class that does an eval on the inputted string and creates an associative array.]]> Tue, 21 Feb 2006 06:46:23 -0600