Archive for the ‘Development’ Category
Yesterday marked the release of the last beta version of Puli 1.0. Puli is now feature-complete and ready for you to try. The documentation has been updated and contains all the information that you need to get started. My current plan is to publish a Release Candidate by the end of the month and a first stable release at the end of April.
The most important addition since the last beta release is Puli’s new Asset Plugin. Today, I’d like to show you how this plugin helps to manage the web assets of your project and your installed Composer packages independent of any specific PHP framework.
Today, I would like to show you how Puli’s Discovery Component helps you to build and use powerful Composer packages with less work and more fun than ever before.
Today marks the end of a month of very intense development of the Puli library. On December 3rd, 2014 the first alpha version of most of the Puli components and extensions was released. Today, a little more than a month later, I am proud to present to you the first beta release of all the libraries in the Puli ecosystem!
Since the introduction of Composer and the autoloading standards PSR-0 and PSR-4, the PHP community changed a lot. Not so long ago, it was difficult to integrate third-party code into your application. Now, it has become a matter of running a command on the terminal and including Composer’s autoload file. As a result, developers share and reuse much more code than ever before.
Unfortunately, sharing your work gets a lot harder when you leave PHP code and enter the land of configuration files, images, CSS files, translation catalogs – in short, any file that is not PHP. For brevity, I’ll call these files resources here. Using resources located in Composer packages is quite tedious: You need to know exactly where the package is installed and where the resource is located in the package. That’s a lot of juggling with absolute and relative file system paths and prone to error.
This post was partially triggered by the release of the new Zend Framework 2 Form RFC because I think that a lot of duplicated effort is going on there. I completely understand that Zend Framework 2 needs a form layer that is tailored to the components delivered by the framework. The purpose of this post is to demonstrate that the Symfony2 Form component is perfectly suited for this requirement. Symfony2-specific functionality can be unplugged, leaving only the raw core dealing with form processing and abstraction. As a replacement, functionality can be developed for supporting Zend’s or any other framework’s components.
Creating a generic form library that elegantly solves all the various use-cases that can be found in web form construction and processing has been a challenging, long-lasting and complex task that is not over yet. Cooperating and continuing development from this common base on seems like a big chance to make form handling in PHP more powerful – and easier – than it has ever been before.
Unit testing is a very important task of professional, scalable software development. Many tools exist to support unit testing in one or another way. All tools come with advantages and drawbacks. One of the best known test frameworks in the PHP world is PHPUnit. With the release of symfony, Fabien Potencier released another new testing framework for PHP: lime. The biggest advantage of lime over PHPUnit surely is the conciseness of the written test code. There are several disadvantages as well, which include bad test encapsulation due to the lack of support for fixture setup and teardown, and missing support for mock object generation.
Today I will briefly speak about the advantages of both frameworks, and how they can be combined to result in a slicker, powerful testing framework. I will show you how easy testing really can be! And you will be able to try it out, because all the required code has already been released in sfLimeExtraPlugin.