Understanding Zend Framework 3 … before it’s out!

Hey guys! Everyone knows how important it is to understand the concepts of a framework to truly use it at it’s best. With Zend Framework 2 (ZF2) a lot of people coming from Zend Framework 1 (ZF1) were shocked at first. So many new concepts, so many new buzzwords and more importantly what’s the need behind all those. ZF2 was a big step forward and by now a lot of people have gotten accustomed to the way ZF2 works and why it does so.

While ZF2 is a great Framework there are still a couple of things that are just not ideal. A little example would be that a lot of people use $this->getServiceLocator() inside their Controllers. While this is OK, it’s actually considered bad practice. The way things are looking right now, this feature will be removed in Zend Framework 3 (ZF3) to basically force people to use proper dependency injection using the ServiceManager.

And that’s what this post is all about actually. ZF3 is not close around the corner. It’s still many, many months ahead. But there are reasons why you should bother and get information about ZF3 as soon as possible. If you understand why changes are introduced – and most of them are explained, some will be explained at a later point i guess – then you can spot errors in todays code already! You can improve your current code by knowing what’s going to be “in” a couple of months away.

Zend Framework 3 on Google Moderator

One way to follow the development is to keep track of the discussions for Zend Framework 3 Ideas on Google Moderator. Not only will you be able to keep track and understand coming changes, you can actually do something against it! Does something sound just not right to you? Counter-Argument and downvote! ZF3 as much as ZF2 is a Community-Project and if the absolute majority of the community is against a change, chances are quite high that a change won’t happen.

ZF3 Tagged Issues on GitHub + Wiki

Probably the most technical information you can get is available right inside the ZF2-Repository over at GitHub. All Issues / PRs with the Tag ZF3 are about the very topic of introducing or debate about changes happening within the development of Zend Framework 3. This would be the ideal place for you to get involved with the actual ZF3-Development.

Aside from the issues on GitHub, there’s also a Wiki-Entry which lists a lot of the changes in a little more comprehensive format. More specifically, it lists up all the bc-breaks that are happening, so wisely read those! Thanks to Bakura for pointing that out.

Google Hangouts for Zend Framework 3

This actually is the core of this Blogpost. Just today i learned about a great Project that some of the great minds behind Zend Framework started. Marco <Ocramius> Pivetta, Evan <EvanDotPro> Coury and Ben <DaspriD> Scholzen will be holding a regular series of Live-Videos / Hangouts where the will be talking about the current status of development of ZF3. They will be highlighting some of the core changes and give reasons for why they are doing so. In addition to that you will be able to ask live-questions via chat at #zftalk.dev @freenode.net

I can only suggest to you guys to follow at least those hangouts. This will be roughly an hour worth of your time to understand Zend Framework 3 before it’s even out!

Follow the Hangouts here: Zend Framework 3 Status Hangouts. The first one will be held at November 6th at 15:00 UTC. Mark you calendars guys!

Clip to Evernote
12 Responses to Understanding Zend Framework 3 … before it’s out!
  1. Mike Reply

    Your posts are lifesavers Sam! That said, I’m moving to the node.js camp before PHP & ZF collapse under their own weight.

  2. Dominic Reply

    It’s not understandable: $this->getServiceLocator() only works, if the ServiceManager has been injected into the controller before (via setServiceLocator, called by the controller manager just after initialization).

    The ServiceLocator had been “injected” to become the value of the property “serviceLocator” in the controller; the get-Method just gets this “injected” instance. This implementation would not change, if you hand-over the ServiceLocator directly into every method in need of it.

    Btw. the only way to inject the ServiceLocator by every call would be to get the ServiceLocator from a global resource – which is the Registry implementation the framework just got rid of.

    I don’t think this idea will remain.

    • Sam Reply

      Dominic, you misunderstand the core of the problem. Yes, ServiceLocator is available once it is properly injected, BUT, as the Name implies, the ServiceLocator is a Locator. It is not the dependency itself.

      This means that you can’t really see what dependencies your controller has. Imagine a Controller with 2000 Lines of Code. #1 bloated Controllers suck. #2 you’d have no idea how many dependencies are used within this controller. What TableGateways are used. What Services are used. Anything else?

      A proper programatical way would be to require ALL dependencies at the __construct() of your controller. That way you'd instantly know what dependencies there are. You may argue that you'd have some dependencies that are used within one action and some additional dependencies that are used within other actions. So naturally there will be overhead when using Action #A that only needs dependencies #1 and #2 even though at the __construct() we also injected dependencies #3, #4 and #5, right? In this case, let me argue that your controller is bloated. It'd probably be wise to separate the functions that require additional or separate dependencies into their own Controllers. Personally my controller only has one dispatchable *Action() and that's a pretty good approach i'd say.

  3. Frank Abel Reply

    Thanks for this excellent post Sam!
    About:

    A little example would be that a lot of people use $this->getServiceLocator() inside their Controllers. While this is OK, it’s actually considered bad practice.

    I’m not sure that such pattern must be considered a bad practice at all. Take a look here to see a serious discussion about this issue. Others elements to take in consideration can be found at here

    Still I think that until someone write/think how could be the alternatives to this pattern and describe its advantages and disadvantages, we should be more careful to state that “it’s actually considered bad practice”. I have a about this.

    • Sam Reply

      Often times with changes like this there’s lot’s of discussions surrounding it. While there’s certainly some valid points from the “contra-”people, overall i’d argue that the example “You don’t bring a full hardware store home to build yourself a computer” is more than valid. Personally i think that cleaner dependency injection is a huge plus and will make all of us better developers in general. Huge + on unittesting. Thanks a lot for those links tho, very interesting cutouts!

      • Frank Abel

        Hmm, service locator seem to more as an e-commerce site that the full hardware store itself ;)

        you can see what Fowler think about.

        P.S. Can you edit (or point me how to do edit) my previous comment? Seem to me that I messed up with the HTML tags an the comments are broken (links title too long, etc.)

        Thanks.

  4. Fernando Reply

    Why move to ZF3 at all?
    Why not stay in ZF2?
    Is the community pushing for the change or just the main devs?

    Best regards,

    • Sam Reply

      Well, ZF2 will be around for quite a while, so no one has to be in fear of ZF3 being around anytime “soon” ;)

      Furthermore, the change towards ZF3 won’t be as big of a switch as ZF1->ZF2 has been. ZF3 will fix a lot of “problems” that are currently persisting in the code. You can read about those in the links i’ve given in the article. ZF2′s development – to my knowledge – will focus on Bugfixing without implementing major backward compatibility breaks.

      With ZF3, that’s a different story. While there probably won’t be many super new features, quite a few pieces of the code base will be rewritten. And some of the rewrites are happening to the core-features of ZF2 Applications, mainly the ServiceManager and/or the EventManager. Changes there have huge effects on existing applications and will likely introduce major BC Breaks. For this very reason those big changes are scheduled for a major release with ZF3 and not somewhere in the middle of ZF2.

  5. mo ho Reply

    How about using Symfony2 and forget about the waiting. If you can.

    • Sam Reply

      Following the development of a Framework has nothing to do with the specific Framework itself. ZF3 will be nothing but a “big milestone” after ZF2. Symfony on the other hand goes much slower when it comes to Major Version releases. However this doesn’t mean that under the hood less is changing. It’s just a differential in Versioning, no more, no less. Absolutely no reason to choose one framework over the other ;)

  6. Michaël Gallego Reply

    You could also add a link to the wiki for backward compatibility: https://github.com/zendframework/zf2/wiki/ZF-3.0-Backwards-Compatibility-Breaks

    I’ve made all the efforts to keep it up to date with various PR I’ve made so far :) .

  7. Evan Reply

    Great post, Sam. Another quick tip for following the progress of ZF3 is to check out the issues and pull requests tagged with “zf3″ on GitHub.

    https://github.com/zendframework/zf2/search?q=zf3&type=Issues

Leave a Reply

Your email address will not be published. Please enter your name, email and a comment.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">