Archive for the ‘Thinking Ahead’ 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 Web Resource 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.
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.
Keeping all parts of a website consistent is one of the most time consuming tasks of a web designer. Spending this time is worth doing, because the more consistent the look and feel of your website is, the more professional it appears to its users.
I will show you today how symfony could help you keeping all of your forms consistent with very little work left for you to do. Read the rest of this entry »
Today I want to follow up on my last post about improving the forms in symfony. David Hermann wrote a quite interesting reply on his blog. I want to take some of his ideas and enhance them even further. The goal is to be able to reuse as much code as possible when creating applications with lots of different forms.
This post will be different though. While I only made assumptions in my last post without any code verifying that my ideas are implementable, I do have a prototype implementation now. Read the rest of this entry »
After my last post about simplifying symfony and especially the forms framework, I started diving into the forms framework to find out how we could improve it. I tried to find ways to improve the usability of this framework without reducing its mighty possibilities. Quite the contrary, I think that the forms can be made even mightier than they are now. Read the rest of this entry »
Welcome to all of you on webmozarts.com! Whether you are a PHP developer, a symfony power user or just getting started in object-oriented web application development – this blog is for you.
With our first post, I want to talk about symfony and where this blog is heading. And I don’t mean “symphony” as in music – no! Scrap that “ph”. It’s “symfony”, one of the greatest web frameworks that has been developed in PHP5 so far. (If you ever dare to write symfony with “ph”, tiny kittens will suffer!)
Symfony is by a large part a product of Fabien Potencier’s ingenuity and dedication. I want to deeply express my respect for his work at this point. The framework is a very well-thought piece of work and can immensely boost your productivity.
The amount of features and the complexity come with a drawback though: It takes a lot of time to learn how to develop efficiently with symfony. Many PHP developers are overwhelmed by the object-oriented concepts applied in the framework. Many call for a simplified version and I must agree that symfony suffers some usability problems lately. But why is that and how can we improve the current situation? Read the rest of this entry »