Zend Framework and OXID eShop

OXID eSales is considering to integrate Zend Framework (ZF) in the OXID eShop product.

Why does OXID raise the question to port the eShop product to Zend Framework?


Actually its not because of technical reasons. The OXID eShop framework itself is well grown over the years, robust and fast. OXID users and partners know it already. So why raise this question then? The OXID eShop framework is a single-purpose framework, solely designed for this product. Meaning that it is fast, no unnecessary overhead. But there is also another side to this medal: Single purpose means no extras either. If a module writer wants to use generic components the shop doesn’t include itself yet, then he needs to make up something on his own. Hence, it might be an advantage to have generic components available from within OXID eShop.


The biggest driver for OXID in many decisions nowadays is to see if we can attract more people joining the eShop community. For that it may be beneficial to include a generic component framework into the shop. I think a complete application-stack-kind-of framework where the classes are more coupled together will not fit well into our product. A component system on the other side will rather meet our expectations. Main requirement should be that the components are as much decoupled and useful on their own as possible. The idea is that you can use whatever component you want whereever you want.


With this is mind, the Zend Framework seems to be the most obvious candidate. Why?
 

• Many developers know Zend Framework and are using it.
• There is much documentation available 
• Zend Framework is continuously being developed by an active community
• Getting certified is a possibility. 
• Some people think that Zend Framework will be _the_ PHP framework from now on.
• Ok, to be honest, OXID does indeed have Zend Framework know how, given that our eFire platform (currently only available in Germany) is based on it. It’s easier for us to use Zend Framework then using an framework we never actively used before.

Integrating Zend Framework or any framework for that matter, is a big step. Many questions need to be answered first.
 

• The basic question: Do we actually want to use an generic component framework in our shop ?
• Do we want to replace all fundamental core classes with Zend Framework classes or only the classes where the Zend Framework offers more functionality and/or better performance? 
• Do we want to strip down the eShop framework in favor of the component framework? 
• The eShop framework is just there for the product. A generic framework serves many scenarios. Do we have to fear an performance degradation? If inevitable, how much degrading are we willing to accept?
• The module writer needs to keep its module compatible with OXID eShop framework already. If we always package the current Zend Framework with the shop, the module developers need to stay up to date with both. Is that ok?

Some of these questions involve issues which will translate into a lot of programming work - resources that will not go into feature development if we do them. There is definitely a trade-off.

We will try some spike solutions in the near future. I will keep you informed on that.

We would like to hear from the community what you think. Please join the discussion on the dev-general mailing list, leave a comment to this blog or in the related forum thread.