The PHP Roundtable podcast, hosted by PHP community member Sammy K Powers, has posted a new episode: Episode #78 - DocBlocks, Annotations, PSR-5 & The Like. In this show Sammy is joined by * Chuck Burgess*, Marco Pivetta, Rasmus Schultz, Margaret Staples and Alexey Gopachenko

We discuss DocBlocks, PSR-5, Annotations, reflection, automatic API documentation generation, and their future in PHP.

You can catch this latest episode either using the in-page video or audio player or by watching it directly on YouTube. If you enjoy the episode, be sure to subscribe to their feed and follow them on Twitter for updates when new shows are being recorded and released.

The SitePoint PHP blog has posted a tutorial from Bruno Skvorc showing you how to use Rauth, a tool that's designed to control access to parts of your application as set by annotations in the code.

Rauth is SitePoint’s access control package for either granting or restricting access to certain classes or methods, mainly by means of annotations.

[...] Traditional access control layers (ACLs) only control routes – you set anything starting with /admin to be only accessible by admins, and so on. This is fine for most cases, but not when: you want to control access on the command line (no routes there) or you want your access layer unchanged even if you change the routes Rauth was developed to address this need. Naturally, it’ll also work really well alongside any other kind of ACL if its features are insufficient.

He starts by dispelling the common thought (at least in most of the PHP community) that annotations are a bad thing and relying on them for functionality isn't a good practice to follow. With that out of the way, he shows a simple example: a set of users and fake routes that are evaluated by Rauth based on the annotations in a One controller-ish class. He describes what the evaluation is doing and how changing the annotations would make a difference in the results. He also includes a dependency injection example with PHP-DI and the Fast-Route package and a more "real world". He ends the post with a look at another handy feature of the library: bans (blocking based on other types of annotations, @auth-ban).

In this new post to thePHP.cc blog Sebastian Bergmann (creator of the PHPUnit unit testing tool) questions of some the current "best practices" involved in using the tool. More specifically he looks at the handling for expected exceptions and proposes a new practice to use going forward.

It is important to keep in mind that best practices for a tool such as PHPUnit are not set in stone. They rather evolve over time and have to be adapted to changes in PHP, for instance. Recently I was involved in a discussion that questioned the current best practice for testing exceptions. That discussion resulted in changes in PHPUnit 5.2 that I would like to explain in this article.

He talks about the currently widely used practice of the @expectedException annotation to define when an exception should be thrown from the code inside the unit test. Sebastian talks about the evolution of this into other annotations around the code and message returned from the exception too. He then proposes the new best practice as a result of some discussion around the annotation method: returning to the use of the setExpectedException method. He provides some reasoning behind the switch including the timing of the exception being thrown (not just "any time" but a more specific time).

In this post to his site Matt Stauffer walks you through how he created a custom @requires annotation to use in his PHPUnit testing. He needed a way to tell a test to only run if it wasn't being executed on the Travis CI service.

I was working on a project this weekend that required skipping certain tests in a particular environment (Travis CI). [...] I remembered that there was a @requires annotation in PHPUnit that works natively to allow you to skip a test under a certain version of PHP or with certain extensions disabled, so I set out to write my own custom @requires block.

He links to an article that helped him get most of the functionality in place but decided to restructure it a bit to make the override of the checkRequirements method a bit clearer. He ends up using the Laravel Collection functionality instead of a basic foreach reducing it down to a closure that looks for an environment variable called TRAVIS and automatically mark the test as skipped.

JetBrains has announced a webinar they'll be holding on June 11th at 4:00pm CEST (10am EDT) with host Rafael Dohms covering annotations in PHP.

Annotations are more than PHPDoc comments, they’re a fully-featured way of including additional information alongside your code. We might have rejected an RFC to add support into the PHP core, but the community has embraced this tool anyway! This session shows you who is doing what with annotations, and will give you some ideas on how to use the existing tools in your own projects to keep life simple. Developers, architects and anyone responsible for the technical direction of an application should attend this session.

Space for the webinar is limited, so if you're interested in attending be sure you sign up quickly. There's no charge for the event, you'll just need to provide a bit of information prior to signup.

The VG Tech blog has posted the first part of a series they're doing about Zend Framework 2 and Swagger, the auto-generating documentation project for APIs. In this first part of the series, they go through some setup and show the use of annotations to define the Swagger output.

So everyone is building APIs now – parsing and outputting JSON is not that hard. Some people even build truly RESTful APIs, or something not to far from that. Before, when building APIs was about SOAP with XML schemas and WSDL specifications, people spent so much time building their APIs that they had the time to think. Now, building an API is so easy and fast that the documentation is often suffering. [...] Swagger is a popular project providing auto generated API docs based on a service specification. This spec is based on annotation comments in the controllers and models, giving the developer a fairly easy, and close to the code way of keeping the API docs up to date.

He walks you through the process to clone and setup the Zend Framework 2 project first, then pull in the "outeredge/swagger-module" with Composer. This package provides the tools to generate Swagger output from annotations in the PHP code. He also shows you how to set up the Swagger UI project (wordnik/swagger-ui). Finally, he gets into the code examples, showing how to annotate models and use partials.

In this new post to his blog, Matthew Weier O'Phinney about some of the recent updates in the latest beta (beta5) of the Zend Framework 2's "Forms" component.

Forms are a nightmare for web development. They break the concept of separation of concerns: they have a display aspect (the actual HTML form), they have a validation aspect and the two mix, as you need to display validation error messages. On top of that, the submitted data is often directly related to your domain models, causing more issues. [...] Add to this that the validation logic may be re-usable outside of a forms context, and you've got a rather complex problem.

He talks about the newly-rewritten form component along with the new InputFilter to accompany it. He includes an example of using this new component - making a User form that, based off of some annotation rules, does some validation on the property values and things like "required" and custom types. He also talks about some of the other features included in the new package like hydration, complex annotation support and tools to work with collections.

You can download this latest beta release from the packages.zendframework.com site.

Matthew Weier O'Phinney has a new post to his blog today looking at visibility in OOP in PHP - less about the features the language offers and more about the theory of their use.

I'm a big proponent of object oriented programming. OOP done right helps ease code maintenance and enables code re-use. Starting in PHP, OOP enthusiasts got a whole bunch of new tools, and new tools keep coming into the language for us with each minor release. One feature that has had a huge impact on frameworks and libraries has been available since the earliest PHP 5 versions: visibility.

He covers a bit of the syntax and features of public, private and protected and mentions a keyword not often seen in PHP applications - final. The reason all of this came up was work on annotation support in Zend Framework 2 and some difficulty in integrating it with Doctrine support. The "final" status of the class was part of the problem, and after a a lot of copy & pasting he decided on a different tactic - using its public API to try to work around the problem.

In sum: because the class in question was marked final and had private members, I found myself forced to think critically about what I wanted to accomplish, and then thoroughly understand the public API to see how I might accomplish that task without the ability to extend.

Mike Purcell has a quick new post to his blog showing how you can run PHPUnit on one specific test using handy grouping functionality already built into the tool.

The other day I was debugging an error in one of my unit tests, and found it hard to track down because when I ran PHPUnit, it ran all the tests contained in the file where my problem unit test was located. After some Googling and reading the PHPUnit Api Docs, I found that you can specify a test, among other tests, by adding a comment with the @group annotation.

Using this "@group" annotation tells PHPUnit to combine these tests and allows you you specify a "--group" setting on the command line to only run those. He includes some sample code showing how it can be used. This can be very useful for combining results for certain kinds of tests (say, all related to bugfixes) without having to run everything all over again.

Andrew Eddie has posted a helpful tutorial for Eclipse users out there showing how to get the most our of code assist in Eclipse PDT/Zend Studio.

One of the powerful features of an IDE like Eclipse is the ability for it to "read" your code and give you some assistance about your API as you type. This could include things like class property or methods names, constants, functions, argument lists, and so on. Eclipse/PDT and ZendStudio do this by parsing a PHP class directly, but they also look at your docblocks and some other special comments where the raw PHP is not enough. This article is a bag of tricks that help you get the most out of code assistance using Eclipse/PDT or Zend Studio in those awkward corners of your code that you might have through previously inaccessible.

Among his tips are things like adding "@var" declarations to help with code completion, type hinting on methods/functions, using the "@property" annotation and using a "this" trick to override what class the IDE sees as the local object. ,/p>