Working with multiple PHP frameworks – The best practice

Working with multiple PHP frameworks – The best practice

Hi, first of all, I’d like to explain the title of this post. I won’t go into depths of complicated examples, but rather explain the logic of it.

PHP first implemented OOP (Object Orientated Programming) the right way in version 5. OOP is powerful tool in any programming language. But the next logic step was to create framework as an “abstract layer” that will help developers in both speed and quality of their work. To conclude this brief introduction, I’ll say that there are many frameworks written in PHP for PHP. 😀

Now to the fun part. For example I’ll use Magentos framework, that is written over Zend framework. To make stuff just a little bit more complicated. Zend framework is written on top of PHP’s built in functions.

Now, if you are a Magento developer (like we are 😀 ), you need to work by rules, or there will be problems with your Magento modules, extensions, etc. I promise. The problem is if you, lets say, use Zend framework directly in Magento module, which you can (Magento is its “extenstion”, which allows you to call parent methods). Why, you ask me? Well, to answer that, I will ask you a question. What will happen if you upgrade Magento to latest version which excluded some Zend framework functionality from its libraries?

It will collapse your module, and you will have to rewrite it in whole new way. But if you used only Magento functionalities, it will probably work just fine. If not, you can just take Magento functionality in one place, and insert it in latest version, so all your Modules that depend on it, work with “single strike”.

To conclude, you (and I) should never go “one level too deep” when extending a framework written in framework. Not only you will have less problems with updates / changes in parent framework, but you’ll need much less time to fix the problems that weren’t your problem initially.

A small example is in order, I think.

A class “Mage_Payment_Block_Form” extends some “Varien_Object” classes, but on top of that all, it uses Zend_Form, and its methods, to give you most usable class for our Magento platform. But if you use some of Zend_Form’s methods directly, like “setCaptcha”, and Varien decides to rewrite it in Magento (and exclude it from Zend library), all your modules that use that mehod will no longer be functional.

To make a long story short. Best practice would suggest that we all use only top level framework in our projects. Yes, it takes a bit longer (usually) to develop it, but at the end, it pays of big time. If nothing, when some of your colleagues start fixing their Modules, you will have your satisfaction. 😉

I hope this helped someone, and feel free to correct me if I’m wrong.

You made it all the way down here so you must have enjoyed this post! You may also like:

Using Redis cache backend and session storage in Magento Marko Martinovic
Marko Martinovic, | 43

Using Redis cache backend and session storage in Magento

ZendFramework example on using Google URL Shortener service Branko Ajzele
Branko Ajzele, | 3

ZendFramework example on using Google URL Shortener service

Getting started with REST using Zend Framework Branko Ajzele
Branko Ajzele, | 20

Getting started with REST using Zend Framework

16 comments

  1. hello i am new in magento and zend framework my question is what i helper and what is use of helper and how the helper can access the data of module
    i will relay appreciated if you post some article about this
    sorry for my bad english

  2. True, but with Zend you can have a set of unit tests do the checking in 10 seconds (as opposed to Magento which requires hours on end of manual testing after changes)

  3. I wasn’t saying that any change in Magento or Zend causes you to refactor all your code. I was referring to the part of the article where they advise against extending Zend directly, due to the fact that Varien could change or remove the provided Zend functionality without warning. My point was that this is just as likely to happen to Mage functionality as it is to Zend functionality.

    And again, this article (and my comment) were referring to best practice when directly extending Zend/Mage classes…so there is only so much you can do to “de-couple” your functionality from theirs…there will always be some dependency on the class you are extending, and if/when that parent class changes there can be resulting changes in your own code as well. So you obviously aren’t ALWAYS going to have to re-factor, but you are always going to have to check and see what is changing in the classes you are extending when you upgrade to confirm there will not be any conflict with your custom code.

  4. Yeah, there are times when you should and times when you should not use Magento’s methods. For example, generating a URL, you basically have to use Magento (even though its not documented well).

    It goes the other way too. To write automated tests to test your ajax, sometimes you might need to call an admin panel side controller. In this case your dependencies on Magento kind of come back to haunt you – you have to get a way to override the controller, but only during that test, and make sure the overridden controller is not present when you ship to production. All to create a simple test.

  5. @ Josh, I agree. Perhaps I haven’t express myself in the right way in the article… 😀

  6. If Magento making a change or Zend making a change is causing you to refactor all of your code, you didn’t wrap your libraries, or decouple yourself from them – hence the proverbial saying “you’re doing it wrong”

    I admit, sometimes Magento throws me some curveball headaches, but avoiding dependencies works good. I instantiate my blocks via straight PHP, whenever possible, for example. Layout XML was a stupid idea in my opinion. Its just extra indirection for no real benefit.

  7. I agree with Josh.

    In addition, new versions of Magento are just as likely to change/remove Mage functionality as they are to change/remove Zend functionality. If you make the decision to upgrade Magento versions, you are going to have to re-check (and potentially re-factor) all your custom code, regardless of whether you followed best practices when extending core functionality.

    Also, there are plenty of examples of Magento core code making use of Zend classes directly (Zend_Soap and Zend_Http classes come to mind immediately).

  8. Magento team is in denial about unit testing. Therefore it is hard for them to make any changes without introducing new bugs. They have a position open for a senior unit testing – so maybe in another 1-3yrs they’ll have about half of it under unit test.

  9. @ Josh and Ontic
    I agree with both of you – partially. That’s because I don’t think it’s a good idea to use Zend standard module naming. Since we all agree that Magento developers don’t think of some things too much, it can happen that the “change of something” can accidentally include your “custom added” zend module into the Magento itself, which can cause the crash of whole Magento installation.

    I mean, this is the worst case scenario, but it can happen (Murphy’s law 😀 ). And if we talk about some permanent compatibility with Magento’s versions / upgrades, I think it’s best practice to rename them (IMHO). That’s why I wrote it in the article.

    And thanks for constructive critics 😀

  10. Magento must have been one of the early adopters of Zend Framework because allot of the written code doesn’t follow ZF current guidelines and best practices, nor does it use ZF to its full potential. I’m guessing there must be serious compatibility issues with Magento and the current package of ZF because they are still using version 1.9.6 and the current stable release is 1.10.8 Between those releases include allot of bug fixes and new components.

    I agree with Josh, I don’t see a problem with packaging a ZF component with a Magento module if it doesn’t exist. It sure as hell beats re-naming an entire ZF component (sometimes 16 + classes), and having to maintain it within your Magento module.

    Can anyone find out why Magento won’t update ZF? I posted a thread on the forums a while back but didn’t get a response.

  11. Magento is not unit tested, Zend Framework is. I’ve been depending directly on Zend Framework for years with no issues – ZF team understands basic concepts like backwards compatibility, that Magento team does not. It does not take a brain surgeon to ship a copy of a given ZF component along with a Magento module, if Magento removes that component from their package.

  12. @mageteam

    I agree if there’s no built in functionality, but I wouldn’t use Magento’s Zend library directly, but rather as include in my Module.

  13. I agree that sometimes it’s faster to simply extend something, and in Magento, I’d extend Mage, because it’s logical. But I wouldn’t extend anything from Zend framework, because Magento is built on top of it.

    And if Varien would decide to remove component you (perhaps) used, you’d have a big problem with upgrades, especially if you used it in a decent amount (because you’d have to redevelop your modules, right?).

    That’s why I wrote only to extend classes only one level up.

    As far as the question with Zend component… IMHO, I’d pack it my module, and work from there, and do some renaming, so that if will work independent from everything. In all next Magento versions (on assumption that module logic would be supported in next versions).

  14. In my opinion its no problem to use Zend Framework directly, if there is no same funtionality inside Magento.

    @ontic: in magento you can also overwrite classes and methods from the Zend Framework library. I also use Zend Framework directly (e.g. Zend_Validate()) .

  15. Personally I don’t believe there is a “Best Practice” when it comes to class inheritance, particularly when using Magento. What I typically do is assess the class I would like to extend and determine how much code/functionality can be inherited, if very little change is required (e.g. overriding a single method) then I will extend from the top level class. When allot of changes are required, I usually extend from an abstract class or interface.

    In the case where Magento changes it code and it doesn’t suit my needs, I’ll override the method using my own logic and then simply notify customers to update the extension.

    I recently had a situation where I wanted to use a Zend component which isn’t packaged with Magento, as an extension developer, I’d be interested to hear how you guys would handle that.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <blockquote cite=""> <code> <del datetime=""> <em> <s> <strike> <strong>. You may use following syntax for source code: <pre><code>$current = "Inchoo";</code></pre>.

Tell us about your project

Drop us a line. We'd love to know more about your project.