On NetTuts.com today there's a new tutorial posted about "taming" Slim 2.0, the latest version of the popular PHP microframework. They look at application structure and share some tips to using this update.

Slim is a lightweight framework that packs a lot of punch for its tiny footprint. It has an incredible routing system, and offers a solid base to work from without getting in your way. Let me show you! But that's not to say that Slim doesn't has some issues; it's one-file setup becomes cluttered as your application grows. In this article, we'll review how to structure a Slim application to not only sustain, but improve its functionality and keep things neat and systematic.

He starts with an example of "vanilla Slim" and looks some at what's happening behind the scenes in the routing engine. They then give you a step by step installation and usage guide including updating the router to use class files. An example controller is included as well as some basic error handling using a Twig template for use across the application.

Matthew Weier O'Phinney has posted the second part of his series looking at creating RESTful APIs with the Zend Framework v2. In the previous post he covered some of the basics of data and structure. In this new article he looks at content types, status codes and two ways to represent them back to your users.

In my last post, I covered some background on REST and the Richardson Maturity Model, and some emerging standards around hypermedia APIs in JSON; in particular, I outlined aspects of Hypermedia Application Language (HAL), and how it can be used to define a generic structure for JSON resources. In this post, I cover an aspect of RESTful APIs that's often overlooked: reporting problems.

He starts with some of the things around error handling and APIs that bother him and why just returning a status code representing an error isn't enough. He suggests two possible solutions to this issue - two messaging formats, API-Problem and vnd.error. He gives brief summaries of each and includes example output to give them some context.

PHPMaster.com has posted a new article with some high level security tips and reminders for PHP developers when wanting to help prevent issues with their applications. The article provides eight tips, each with a brief description.

When it comes to application security, in addition to securing your hardware and platform, you also need to write your code securely. This article will explain how to keep your application secure and less vulnerable to hacking.

The good practices they recommend include input data validation, protecting against XSS attacks, preventing SQL injections, protecting session data, proper error handling and protecting included files. There's some good reminders here, but it barely scratches the surface of effectively protecting your application. These tips are the "low hanging fruit" for securing your app, so be aware that there's more things to worry about than just these eight.

Recently Lorna Mitchell asked the wide world of Twitter about some of their recommendations of things not to do when creating an API. In this new post to her site, she gathers together those responses including comments about documentation, consistency and response codes.

Recently I tweeted as a #linktuesday link the 10 Worst API Practices post from ProgrammableWeb. Today, in search of some concrete examples of APIs implementing unhelpful antipatterns, I sent out a tweet for help: "What's the most frustrating inconsistent/misleading bit of API you've seen? Looking for cautionary tales!" [...] In the raft of responses (and thankyou all, this was fabulous, helpful and entertaining in equal parts!), there were some definite patterns that I'd like to share with you, in no particular order.

Comments came in from all over and talked about things like:

• Response codes not matching the content (ex. 200 on an error)
• NullPointerExceptions
• Different endpoints for single vs collections
• Order-sensitive XML in requests
• Poor error handling
• Bad documentation
• Incorrect content type handling

So there you have it, the sins to avoid in your own APIs. If you've encountered any of these, please accept my condolences.

On PHPMaster.com there's a new article that suggests that suppressing notices thrown from your code is a bad practice to get into, both through error reporting and the use of the suppression operator, "@".

The PHP notice suppression operator is somewhat of a controversial topic in many circles. Some overuse it, some don't use it at all, and some don't even know it exists. Apologies in advance for the horrible code you're about to witness in this article, but it serves a purpose to illustrate the usefulness (or lack thereof) of the suppression operator.

He talks about some of the common notices and how the suppression operator prevents the "Notice" message that could come out of it. They suggest, however, that there's never a good time to use the operator, especially during development. Obviously, there are a few cases (they point out one with mail) where it could be useful. There's also some sample code for a custom error handler you can use to capture the issues that might come up.

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.

Timothy Boronczyk has written up a new post that looks at using assertions in PHP - the actual use of the assert function to evaluate values in your code.

I stumbled upon assertions in PHP today, though why I didn't know they existed after working with the language for so long and what I was looking for originally when I came across them are both mysteries. And with the increasing focus on software quality in the PHP community, I wondered why I hadn't seen them used by others. I decided to ask around, look into PHP's implementation of assertions, and do some tinkering.

He talks some about their usage, some of the common issues surrounding them and compares using them directly on return values vs evaled strings. He also includes an implementation of them in a bit of sample code - a class that uses them (and an assertion callback) to handle the throwing of exceptions.

Assertions are meant to identify program logic/design bugs, not as a run-time error handling mechanism. Isn't this why we do unit testing? Playing devil's advocate, what's wrong with pushing unit tests directly into your code if we have doc comments that are extracted for documentation?

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.

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.

For the Symfony2 users out there, Dean Clatworthy has a handy tip to help you customize the output of your application a bit more - a method for styling the error messages coming from forms using a custom template.

I spent a large portion of my day today trying to customize the HTML produced by Symfony 2 for form errors. The documentation has a section on how to do this, but for the life of me, I could not make it work. Here is a working, re-usable solution.

His solution involves the creation of a template in your "/Resources/views/Form/" directory that contains a Twig template for the error set output. This is then applied in your view using an additional parameter on the error output tag, including this new template from the "Form" directory. This sort of styling could also be applied if you needed custom elements with their own layouts in your forms as well.