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?
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.
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
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.
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.
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
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.
Symfony2 features a brand-new Form component that, to my knowledge,
supersedes most existing PHP form libraries in functionality and extensibility
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
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.
This guest post was written by Klemens Ullmann-Marx, a web
developer in Vienna and founder of the company
Stumbling over a post in the symfony-users list I wrote down some information on
how we manage mobile sites in our ullright platform. There's an old blog post
about creating a symfony iPhone view. Most of it is still valid and it works.
But there is one serious drawback: You have to provide a mobile template for
each action. That's why we created a tiny patch to provide a fallback to normal
templates in case there is no special mobile one.