Over on NetTuts.com today they've published a "one stop guide" to creating Laravel commands that can make using the Laravel PHP framework simpler. The format for these commands are more related to the Laravel 4 version of the framework (still in beta).

In this day and age, it's quite normal for a developer to have an understanding of consoles, and how to issue basic commands. But what if you could code your own custom commands to improve your workflow? If we look back to Laravel 3, you might remember that it offered tasks. Tasks were extremely helpful, but still came up short for more complex operations. Thankfully, Laravel 4 packs a beefed up Artisan that will make your life as a developer so much easier!

They start by introducing you to Artisan and what it can do already, then move into how you can create you own custom commands (with code examples). They show you how to add a description, coloring for the output, work with arguments, use confirm/question prompts and working with dependencies you might need.

In his latest post Joshua Thjissen looks at the creation of a custom configuration loader for a Symfony2 application. This kind of thing is mostly useful for parsing configurations that Symfony2 doesn't already know how to parse.

It happens more and more: large projects where your symfony2 site is just a small part in the big picture. Lots of additional components might even play a bigger part, especially when you are dealing with asynchronous components which are connected through message queues for instance. [...] Our first idea is obvious: symfony2 uses by default a parameters.yml file, which gets imported by your configuration (config.yml) [...] So nothing new here and this setup works perfectly, provided that your symfony2 project is the ONLY thing that needs to be configured. As soon as you add multiple other components (like gearman or activemq workers that need to connect to solr too), they need to share this configuration.

His solution involves falling back to the INI-file format that's known as useful for several different languages and tools. Because of how Symfony2 reads these files though (only looking for "parameters") he's had to create a "ConfFileLoader" instance of the "FileLoader" that uses the parse_ini_file method to parse the data and return it back to the main container as parameters. He also includes the code/config you'll need to implement this custom loader into your application.

On PHPMaster.com today they have a new post from Remi Woler about "exceptional exceptions" - using exceptions to handle the flow of your application's execution a bit better.

Unlike errors, exceptions are designed to be handled by the calling code and will bubble up the execution chain until they are caught. Code in the current scope will stop executing as soon as an exception is thrown (so any lines after a throw statement won't be executed) and control is handed back to the first matching exception handler (either a catch block, configured exception handler, or language-provided exception handler). Only when an exception is caught will code execution continue from there. This article does not aim to teach you exceptions at a 101 level, but instead gives an opinion on how to use exceptions better

The post helps you determine the difference between an error and an exceptional event and gives examples of the sorts of things he considers exceptions useful for. He also talks about throwing different kinds of exceptions to make their context more meaningful, but notes that this has been known to cause trouble if used too much.

In summary, only throw exceptions when your code cannot complete the requested instruction with the given input, always throw a custom exception that actually tells the calling code what the situation is, and if you call other code then only catch the exceptions that you can and should handle.

On PHPMaster.com today there's a new post for all the Zend Framework (v1) users out there. In it, Aurelio De Rosa shows you how to set custom error messages for elements in a Zend_Form.

In this article I'll show the solution to a common problem which arises when a developer has to create a non-English website or application that is based on the Zend Framework. How do we mark a field of a Zend_Form which is a Zend_Form_Element as invalid, showing one or more custom error messages? The problem is mainly caused by the native counter-intuitive methods of the Zend_Form_Element class which I'll explain in more details.

He's included a basic example showing the creation of a form and the setup of a text element and some validators to match. He makes a controller and view to handle the output and submission then shows how to use "setErrors" (and "setErrorMessages") of the Zend_Form elements to setup that custom error. This only lets you set one message, though, regardless of the point of failure. To stop things when there's an error, you have to set the "breakChainOnFailure" parameter on the validator to false - then the message will make more sense.

Juan Treminio has a new post to his site today talking about Composer and namespacing and shows you how the two work together to make using 3rd party tools easy.

You've heard of Composer, right? The nifty new tool for PHP that aims to centralize and streamline package management? Do you also know of, but don't really understand how namespaces work in PHP? Then let's set you straight! In 5 minutes you'll learn how Composer's autoloader and namespaces work!

He's broken it up into a few sections:

• Getting Composer up and running
• Making a basic "composer.json" file
• Going through what the "install" creates (including the "autoload_namespaces.php" file)
• Using the vendor/ autoloader

As a bonus, he also shows how to implement your own namespacing in the "composer.json" file if you have a special case - just use the "autoload" section in the configuration (examples included).

Over on PHPMaster.com there's a new post for the unit testers in the audience (you all unit test, right?) from Matt Turland about testing error conditions in your applications.

Let's say you're maintaining code that uses PHP's native trigger_error() function to log error information. Let's also say that you're in the process of using PHPUnit to write unit tests for that code. If you refer to the PHPUnit manual, there's a section that deals with testing for error condition. [...] However, depending on what your code looks like, it's possible that you'll run into a problem with PHPUnit's approach to this. This article will detail what this problem is, how it impacts your ability to test your code, and how to go about solving it.

He points out that, since errors and exceptions handle differently, you have to work with them differently in your tests. PHPUnit has a feature that automatically turns errors into a specific type of exception when they're thrown and how, by using a simple custom error handler, you can more correctly tests error vs exception.

PHPMaster.com has a new tutorial posted showing how you can work with the Amazon DynamoDB to store session information from your PHP application (originally posted on CloudSpring).

This tutorial will show you how to use Amazon DynamoDB as a storage facility for PHP sessions. This method becomes very useful when your applications take advantage of the Elastic Load Balancing and Autoscaling services. You will need Amazon AWS account enabled to use EC2, Elastic Load Balancer and DynamoDB as a prerequisite to play along the tutorial.

He starts with a description of what the elastic load balancing service is and how it autoscales. He shows how, based on this demo application, to use a custom PHP session handler that implements the Amazon SDK libraries to hook into the DynamoDB service. Also included are screenshots (and the steps that go with them) to configure the service itself.

In his latest post Robert Basic looks at working with custom view helpers in your Zend Framework 2 application and shows how to implement a simple one to display a simple greeting.

I took the skeleton [Zend Framework 2] application, made it even skinnier by throwing out some (for me) unneeded parts and just put it all besides my old ZF1 code. [...] The first problem I ran into was using custom view helpers, especially view helpers that are more general and don't fit into one specific module. Where to put the code? How to access them in views? The second problem was how to access the service manager from a view helper? And the third problem was how to tell the helper to use a specific value when inside a specific module?

He includes a simple example - the greeting helper - and shows where to place it in the application structure, how to work with the service locator inside it and how to set up some module-specific views inside.

Thomas Weinert has a new post to his site showing some of the things that iterators can do for you (including working with arrays and aggregation).

Basically Iterators provide a list interface for an object. Like all interfaces they are a contract how something can be used. If you use an interface it is not relevant how it is implemented - the implementation logic is encapsulated. It is of course relevant on the integration level. A bad implementation can impact the performance of you application. Even an good implementation may need special resources (like a database). But all this does not impact how you use it. Your code using the object with the Iterator interface stays the same.

He shows how to use the IteratorAggregate, ArrayIterator, FilterIterator and how to create a custom Iterator that you can extend in your own code.

In this new post to the TechPortal, Gavin Corbett introduces you to Zend_Form elements (a part of the Zend Framework, v1) and how to create a custom one.

Creating forms in Zend Framework (ZF) is easy, but creating and managing complex forms can get messy! Using config files is perfectly good if you use standard Zend Form elements; it is quick and easy to setup a form in a few minutes however you will have limited control over how the form is rendered. If you want to display your own custom form element correctly in Zend Framework then some configuration is needed in order to achieve this with a config file.

He includes an example of first creating a basic form with a header and a single field element and validating the results of the submission. Building on that, he shows you how to create a custom "EmailAddress" form element and how to add in a view helper to style the output a bit.