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.

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.

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.

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>]]> Thu, 01 Dec 2011 12:55:32 -0600 http://www.phpdeveloper.org/news/17085 http://www.phpdeveloper.org/news/17085 PHPUnit is one of the most widely used unit testing tools for PHP applications. It comes packed with features, some that are commonly used and some not so much. In a new post to his blog today Volker Dusch looks at one specific feature - the "@covers" annotation you can use in your tests' comments to specify which functionality you're actually testing.

One of the goals of your test suite and the coverage report is to make you trust in your code base and to remove the fear of changing something that needs to be changed. [...] You shouldn't think "Well yes that a 100% but a lot of that just comes from that big integration test and I don't know if the class is really tested!". [...] Thankfully PHPUnit offers a way to drastically increase your confidence in what you actually have tested.

Using the "@covers" annotation on your test method docblocks gives you one more level of confidence in what's being tested and can help make for clearer updating down the road. He also mentions using them to provide extra insight into protected methods in your code and where the test coverage for them really lies.

PHPUnit has lots of advanced features that can be amazingly helpful when that special case comes around. This includes extending the framework itself, making test suites, building static datasets, and the focus of this article: annotations and mocking. Don't worry if you're unsure what either of these are; I'm here to help. I trust by the end that you'll see how these two features can be useful to both you and your tests.

The article starts with annotations showing how they can be used both on the class side to help with test generation and on the test side to help in evaluation (like expectedException). In the mocking section, it shows you how create simple and complex mock objects to replace a sample database query.

The most simplest reason for this is the idea that annotations are markup. They mark (or, to keep the notion, annotate) code as being special or to be treated in some special kind of way, depending on the scenario where the code is used in. [...] From a design point of view this makes it clear why annotations should not contain logic. If annotations contain parts of such logic, it becomes splitted and possibly cluttered throughout different classes.

He goes on to talk about a second reason why he doesn't think they should be considered first-class in an application - it doesn't promote code reuse. For example, if you define them on a method, there's no way to use that method without them. He puts this into the perspective of the Stubbles framework that currently uses them and how he's changed the logic to live in special classes instead. He considers other changes like places annotations can be used and having different annotation classes.

Anyone who has worked with PHPUnit has most likely worked with expected exceptions and mock objects. The nice thing about working with expected exceptions is that we have access to a handy @expectedException annotation. I've gotten into the habit of using this for exceptions my fixtures should throw but also for when I'm using a mock object to verify a method call.

Some sample code is included to show his problem - a mock object is created for the "foo" class and a test to see if an Exception type is thrown is included on it. The problem is that the exception thrown isn't of type Exception, but of type "foo_exception" and the @expectedException annotation tells it to look for the Exception type. Because of this unpredictable behavior, he suggests not using annotations for these sort of tests or it could lead to false positives.

In this episode, Manuel Lemos and Ernani Joppert discuss several unusual site speedup techniques presented in recent articles of the PHPClasses site blog. They also discuss the (non-)inclusion of new PHP features discussed by PHP core developers like having named parameters in function calls and the support of Java-like annotations in PHP code.

To listen you can either use the in-page player, grab it from iTunes or just download the mp3. Complete show notes and transcript are also included in the post.

Annotations are a really helpful feature in present-day development. An annotation is a special form of syntactic metadata that can be added to source code elements such as classes, methods, properties and parameters. They do not affect the program semantic directly, but can be used by tools and libraries to handle such annotated code in a certain way.

He notes that, as of right now, PHP doesn't naively support anything like this but that there are additional libraries that can be used to augment the standard PHP performance and use them (like a feature in PHPUnit with @assert and @test). He also go through several of the other libraries that make it possible including Addendum, FLOW3 and the XP-Framework.