Navigation

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.

Read the rest of this entry »

Written by: | 2 Comments | Category: Development, Thinking Ahead

Two days ago, I announced Puli’s first beta release. If you haven’t heard about Puli before, I recommend you to read that blog post as well as the Puli at a Glance guide in Puli’s documentation.

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.

Read the rest of this entry »

Written by: | 3 Comments | Category: Development, Thinking Ahead

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!

Read the rest of this entry »

Written by: | 3 Comments | Category: Development, Thinking Ahead

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.

Read the rest of this entry »

Written by: | 7 Comments | Category: Development, Thinking Ahead

Annotations have become a popular mechanism in PHP to add metadata to your source code in a simple fashion. Their benefits are clear: They are easy to write and simple to understand. Editors offer increasing support for auto-completing and auto-importing annotations. But there are also various counter-arguments: Annotations are written in documentation blocks, which may be removed from packaged code. Also, they are coupled to the source code. Whenever an annotation is changed, the project needs to be rebuilt. This is desirable in some, but not in other cases.

For these reasons, Symfony always committed to supporting annotations, XML and YAML at the same time – and with the same capabilities – to let our users choose whichever format is appropriate to configure the metadata of their projects. But could we take this one step further? Could we build, for example, XML support directly into the Doctrine annotation library?

Read the rest of this entry »

Written by: | 8 Comments | Category: Thinking Ahead

Last week, I read a post by Beau Simensen about resource location in PHP. It was interesting, because I had already pondered over this topic in the context of Symfony2. Thinking about how to make Beau’s proposal work for Symfony2 brought me to a result that hit me like a stone. Both he and Amy Stephen made me realize how much this could change not just Symfony2, but the PHP ecosystem as a whole. After PSR-0 and Composer, this is the next important step to ensure interoperability between PHP libraries. And it could almost completely replace the new and hotly debated autoloading PSR. Let me take a few minutes of your time to explain why.

Read the rest of this entry »

Written by: | 12 Comments | Category: Thinking Ahead

Recently, Aura is creating some buzz that components of PHP frameworks should not have any dependencies. To quote Paul M. Jones’ recent article on Aura:

The distinction is that all Aura packages (with the exception of the Framework package) are completely independent, and have no cross-package dependencies, whereas at least some of the components from Symfony2 and ZF2 have dependency requirements.

Or, quoting this article on replacing Silex with Aura.Micro:

I was recently working on a small project that used Silex. As I browsed my vendor folder, I realized how much extra “stuff” I had inherited with Silex. There were a bunch of other components required when all I wanted was some quick and easy routing, micro-framework style.

I think this needs some urgent clarification before this way of thinking becomes mainstream and PHP creeps back into its NIH-hole.

Read the rest of this entry »

Written by: | 30 Comments | Category: Community

Every once in a while, I get into an argument about extending PHP’s Traversable interface instead of the Iterator interface in custom interfaces. The confusion seems to result from the official documentation of Traversable. Let me clarify why you should give Traversable much more love than you do right now.

Read the rest of this entry »

Written by: | 6 Comments | Category: Best Practices

You are joining the Symfony Live conference in San Francisco this year? Good! I will be giving a talk about the Symfony2 Form component and you have the unique opportunity to vote on what I will be presenting. Today I have put up a survey with 23 topics that may find their way into my talk. These topics include questions such as:

  • How can I access the entity in buildForm()? I want to customize my form based on some property.
  • How do I create a collection field with JavaScripts to add/remove rows?
  • There are so many events, when should I use which one?

Which of these topics I will present is entirely up to you. So please take the survey and help me improve your experience of my talk. Oh, and if you take the survey there will be a prize, and a raffle, and one very lucky person… :)

You aren’t joining the conference in San Francisco? Then I also warmly invite you to participate in the survey. Pretty much one year after the first release of Symfony 2.0 and shortly before the release of version 2.1, we are eager to learn what our users are happy about, what they struggle with and what they would like to see improved, both in the usability and the documentation of the Form component. Unfortunately, you won’t be able to participate in the raffle during the conference, but your feedback will tremendously help us to improve future releases of the framework and its documentation.

Take the survey.

Written by: | 4 Comments | Category: Community

Symfony2 features a brand-new Form component that, to my knowledge, supersedes most existing PHP form libraries in functionality and extensibility (not counting the still lacking, native JavaScript support). It has been in development for  two years, even though I was already thinking about it since 2009 and earlier. It is becoming more and more stable recently, with a first completely stable release expected for Symfony 2.2.

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.

Read the rest of this entry »

Written by: | 20 Comments | Category: Development

Additional Resources