In the latest part of his series covering Laravel 5.3, Matt Stauffer has posted this new tutorial covering the new notification system in the latest version of the popular Laravel framework.

In a previous blog post I've covered Laravel's new Mailable feature, which introduces some important changes to how we send mail in Laravel. I'd recommend at least skimming it if you haven't read it yet. In short, the preferred mail syntax is no longer sending mail using the "classic" mail closures, but instead creating a "Mailable" class for each message you want to send—for example, the "WelcomeNewUser" mailable class.

In Laravel 5.3, we have another new feature for communicating with our users: Notifications.

This notification system makes it simpler to send messages to your user when you don't care as much how they get it, just that they do. He walks you through the creation of your first notification class and breaks it down into its main parts, explaining each one. He shows how to define the different handlers for the notification types (like "toEmail") and how to trigger the notification, passing in either a single user or all users in the system. He then talks about the channels that are available to notifications and how to integrate several including Nexmo, database and the "broadcast" channel.

For the MySQL users out there, PHPMaster.com has a new tutorial showing you how to use triggers in your database to perform automatic actions on things like "before update" or "after insert".

By making MySQL do more work through triggers, the PHP side of my project was greatly simplified. So, it is the intention of this article to give you some insight into the creation and usage of MySQL triggers, so that by the end of this reading you can make use of them in your own projects.

They start by explaining what triggers are and how they're created on the database side (with an example syntax). They apply one to a more practical situation - helping keep data integrity on a revenue table based on the data inserted into an events tracking table. Their trigger ("CostCalc") calculates the time of the event on update and updates the revenue table with the correct cost. Also included is the sample PHP code (an "EventHandler") that updates the event records. The trigger fires transparently in the background with no need for the PHP script to make any additional calls.

In this recent post on the Zubma Fitness Engineering site, Chris Saylor looks at using events in your applications to hook in plugins to easily (and dynamically) enhance functionality.

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.

The Developer Drive site has a new post with a few beginner suggestions about how to do some error reporting in your applications:

As much as programmers attempt to anticipate every possible action or combination of actions that a user can take when encountering a web application, no one can foresee them all. When the user takes an unanticipated course of action and "breaks" the application, the software needs to catch them before they fall.

They show you a few methods for handling the errors that might come up including the die function, exception handling, triggering errors and just outputting errors via an "echo" or "print" (or something similar).

Rob Allen has a new post to his blog today introducing you to the ZendEventManager component of the Zend Framework v2, a key part of how this latest version of the framework does its job.

Zend Framework 2's EventManager is a key component of the framework which is used for the core MVC system. The EventManager allows a class to publish events that other objects can listen for and then act when the event occurs. The convention within Zend Framework 2 is that any class that triggers events composing its own EventManager.

He starts with some terminology to get everyone on the same page (listener, event, EventManager) and includes an example of its use in setting up a "PhotoMapper" object showing how to trigger events in the "findById" method. He shows how to listen for a specific event (in his case, a "pre-execute" on the "findById" method) and a method for "short circuiting" the listener based on the response from the "trigger" call. He also touches on the "SharedEventManager" that can be used to add an event across all of your application at the same time.

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 Zend Developer Zone, a recently posted tutorial looks at fetching multiple random rows from a database table (in a MySQL database).

As a follow up to my earlier article about fetching a single random row from MySQL I will tell you today, how you can fetch multiple random rows from a table without any hassle. Compared to the solution with fetching a single random row, fetching multiple random rows requires some tricks.

The tutorial walks you through the creation of some sample tables, making a simple trigger to keep a "random ID" column in a value range of one to the number of rows (gapless) and a bit of PHP code to select some IDs from the table and the SQL to get their information.

Be sure to check out the comments for mentions of the number of table reads and how optimized certain parts of the queries might be.

On DevShed today, there's this new tutorial aimed at more advanced PHP developers concerning how to simulate events in PHP5.

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.

On DevShed today, there's this new tutorial aimed at more advanced PHP developers concerning how to simulate events in PHP5.

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.