Monday, the 17th of November 2014, we were delighted to host a Zend Framework meetup. Not only because it was the first ZF meetup in Paris but also because it was the first time that we hosted such an event. We now hope that through our Zend Framework commitment there will be plenty more. You can join the group on meetup here!
If you prefer to watch (in french) the talks, they are available at the end of the article.
Sophie Beaupuis, Yann Carrier, Corentin Larose and the Paris Zend Framework Community, @inoviateam
Let’s see what was said by our speakers Sophie Beaupuis, and Corentin Larose who also happens to be the organizer of the event.
Future of Zend Framework by Sophie Beaupuis Slides
Zend and Symfony are competitors so we hope not to disappoint anyone of you by saying that “there will not be a ZF3 for a long time..”, knowing that Symfony 3 is announced for november 2015. The thing is that Zend will make its framework 2 much better under the name ZF2++.
Wait what ?! ZF2++ ? Yes, and the explanation is quite easy : many applications are still under ZF1 so releasing a ZF3 would slow down the migration. Sophie Beaupuis said that Zend is aware that some mistakes were made with ZF2 but those same mistakes won’t happen again in the next version.
Basically what is the difference between ZF2 and ZF2++ ? At the moment, each component of ZF2 is dependent on its core. The problem is that the components cannot evolve independently. That is not agile… But, in the new ZF2++, (the information I’m about to release is not official yet), there will be no dependency between the components and the core. Tomorrow, every components will be independant from each other. This will be possible with Composer, making the framework closer to a librairie. But someone else is working hard to make it happen, in a way: the FIG (Framework Interoperability Group).
Have you heard about it ? The aim of such a group is to “talk about the commonalities between projects and find ways to work together“. So far they have established 5 PSR (PHP Standard Recommendations): autoloading, basic coding, coding style, logger interface and improved autoloading. You can contribute to the group and help establishing the next standards!
6 breakpoints by Corentin Larose
You are a developer and you want to learn how to be more productive with Zend Framework? Well, Corentin gave very useful hints on how to debug a Zend Framework 2 application. And let me tell you something: this leads to an enormous gain of time.
ZF2 is an event based framework, so it can be tricky as hell to follow the various steps of a request processing. Why? For example, to display he ZF2 Skeleton homepage there are about 32 events!
There are 5 main steps from the request reception to the page rendering, each of them triggered by an event:
- Zend\MVC\MVCEvent::EVENT_BOOTSTRAP Inject config, discover modules, register event listeners
- Zend\MVC\MVCEvent::EVENT_ROUTE Match URL or CLI args to a Dispatchable class
- Zend\MVC\MVCEvent::EVENT_DISPATCH Call method on the Dispatchable class
- Zend\MVC\MVCEvent::EVENT_RENDER Generate view rendering
- Zend\MVC\MVCEvent::EVENT_FINISH Send response
Depending on the issue you are encountering, you’ll need to dig into one of these main steps (for a 404 have a look at the Routing, for a module not recognized check bootstrap and so on).
In order to achieve that quickly, Corentin’s trick is to put a breakpoint on each of these events trigger in Zend\MVC\Application. You just need to locate the lines matching $events->trigger(MvcEvent::EVENT_*), you’ll then be able to activate/deactivate your five breakpoints to stop execution at the right step.
Wait, title was “6 breakpoints”? Am I missing something?
The fact is, for each of these events, a lot of listeners can be notified and a lot of things can happen. It might be a bit painful to go through everything if you pinpointed your bug in one of those. That’s when the 6th breakpoint comes in handy, you’ll put it in the listener triggering loop in Zend\EventManager\EventManager on the following line $responses->push(call_user_func($listenerCallback, $e));
Debug is as simple as:
- Deactivate the 5 breakpoints
- Activate for example ROUTING breakpoint
- When execution stops at ROUTING, activate listener trigger breakpoint
- Skip until you reach the right listener
- Dig into the methods and find your issue
Big thanks to Sophie Beaupuis and Corentin Larose! We hope it was useful, and if you have any questions feel free to ask them on the meetup group.