Your SlideShare is downloading. ×
  • Like
Symfony and eZ Publish
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Symfony and eZ Publish

  • 2,285 views
Published

Version 5 of eZ Publish is now running on Symfony 2 full stack. This talk will recount this fantastic journey, how the heart of a legacy content management engine was reworked, re-architectured, and …

Version 5 of eZ Publish is now running on Symfony 2 full stack. This talk will recount this fantastic journey, how the heart of a legacy content management engine was reworked, re-architectured, and injected into a Symfony 2 powered HMVC architecture. You will learn how two large technologies merged, what the pitfalls were, how they were overcome, and how these two large communities touched-base and look ahead together.

Published in Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
2,285
On SlideShare
0
From Embeds
0
Number of Embeds
5

Actions

Shares
Downloads
37
Comments
0
Likes
5

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. SymfonyandeZPublish Let’s&have&a&trip&together Jérôme Vieilledent - Software engineer / http://ez.no / http://share.ez.novendredi 30 novembre 12
  • 2. Genesis of the Symfony aspectsvendredi 30 novembre 12eZ Publish 4 released in 2007. More a PHP5 adaptation than a real rewrite.We added features during these years of course, but the main base codekept unchanged.Several attempts were initiated for a complete rewrite (back in 2008 with eZComponents) but the real project began in mid-2010 with a complete re-thinking of our core business API.
  • 3. Requirements • Easily integrate our API • HMVC (Hierarchical Model View Controller) stack • Decoupled components • Dependency injection • New template engine • Extensible, Open, Reliable ;-)vendredi 30 novembre 12API : Working on it for more than a year at that time. Complete rewrite ofwhat makes our core business logic. It’s using DI, but without any containeror any dependency from out there. Completely independentHMVC : In our old model we kind of used MVC, but flawed by too much logicin the view (fetch functions). We needed something that fixes both ourneeds (trigger some logic from the view) and the MVC modelDecoupled + DI : Keep our independency (API is purely independent lib)Templates : Our template engine was way too old, with edge case bugs,very hard to maintain. Plus we wanted flexibility, like being able to easilyswitch from one engine to another.
  • 4. Get rid of the (old) monolithvendredi 30 novembre 12And of course our approach was monolithic (legacy PHP 4 ages, weak OOmodel).Lots of extension points, but interdependent, impossible to decouple,impossible to test properly (singletons everywhere)
  • 5. Get rid of the (old) monolithvendredi 30 novembre 12And of course our approach was monolithic (legacy PHP 4 ages, weak OOmodel).Lots of extension points, but interdependent, impossible to decouple,impossible to test properly (singletons everywhere)
  • 6. Useful things start in a barvendredi 30 novembre 12Lisbon conference, almost all eZ engineering, in an informal beer meeting(probably the best way to make meetings ever). Community guys were heretoo. We became to chat about what would be eZ Publish 5 (after some morebeers, so that we were too drunk to fight).Sharing one’s experiences with Twig, Symfony2, Zeta... We started toimagine how would the paper gift around eZ Publish API would be
  • 7. Options • Home made • Zeta Components • Zend Framework 2 • Symfony 2vendredi 30 novembre 12Home made : Why would we do that ? Too much work for what ? Doing thesame mistakes than in the past, just because otherwise it would be «notinvented here» ? NoZeta Components : eZ has a long story with them. Back in 2008-2009, theirdestiny was to become the next generation of eZ Publish. For severalreasons it didn’t happen. And to be pragmatic, it would have been a lot ofwork to adapt them to work with DI or HMVCZF2 : Still immature at that timeThen Symfony2 looked as an obvious and reasonnable choice. Furthermoreit’s heavily used, has a very active and nice community, and easy to learn.Let’s do it !
  • 8. Backwards Compatibility *Knock knock* devs: «Whos there ?» «Product Management» devs: «Product Management who ?» «PM who wants to talk about BC» devs: «Oh crap...»vendredi 30 novembre 12Then the trouble began. We could have picked any other choice, the sameproblem would have come anyway.
  • 9. BC: The challenge • 100% data compatible (same database schema) • Include legacy templates in new ones • Routing fallback • Load legacy content templates with legacy rules • Settings • Access Symfony services from legacy modulesvendredi 30 novembre 12Data compatible : The most important. One can easily switch from a legacyeZ Publish 4.x instance to 5.0
  • 10. BC: The challengevendredi 30 novembre 12
  • 11. BC: The challenge PM SCRUM Story: «As an eZ Publish user, I don’t want to be pissed off by a new #@!$% version!»vendredi 30 novembre 12eZ Publish 3 use case (2003). Major change => eZ Publish lost the 2/3rd ofits users, community members... Because there was no BC at all.
  • 12. BC: The challenge Challenge acceptedvendredi 30 novembre 12Obviously we didn’t have choice...It was basically trying to make a square fit inside a smaller triangle.2 completely different systems, with 2 completely different approaches.We got inspired of what guys from the Symfony community made whenSymfony 2 came out, to make their Symfony 1 application work with it.
  • 13. BC: The challenge Sandbox Legacy code ...in a Closure !vendredi 30 novembre 12Code speaks like a thousand words
  • 14. BC: The challengevendredi 30 novembre 12So yes of course, we needed to refactor a lot the old kernel (esp. the oldfront index.php and reduce it from 1.000+ lines to a dozen.Using runCallback, legacy code is completely isolated. We can keep highcohesion and loose coupling. Of course it adds some overhead, but it’s fairlyminimal from what it represents.This is the central feature on top of which we built all the requirementsasked. And guess what ? It works !
  • 15. BC: The Architecturevendredi 30 novembre 12
  • 16. BC: Icing on the cake eZ Publish legacy still works independently !vendredi 30 novembre 12
  • 17. From Symfony components to Full Stackvendredi 30 novembre 12When we started to do some prototyping, we needed to dive deep into theSymfony components, to understand how they work together. We alsoneeded to be sure that they were loosely coupled.So we started to use only some of them + Twig
  • 18. From Symfony components to full stack • HttpFoundation • HttpKernel • Routing • Dependency Injection • Bundles • Templating + Twig • Composervendredi 30 novembre 12The more we moved forward, the more our prototype looked like Symfonystandard edition.Of course we started our own glue to tie these components together, in ourown bundles. But we found out that we were doing exactly the same than inbase Symfony bundles (but not that good, because not that generic).
  • 19. From Symfony components to full stackvendredi 30 novembre 12So yes, we had our wheel.But compared to what we could have...So why don’t we simply use and extend main Symfony bundles ? Because it’s«not invented here» ? Let’s be serious.So we took the decision to go for Symfony full stack.Another decision we made was not to put everything in bundles, to be asdecoupled as possible, at least from the full stack framework, to keep ourindependency. We actually realized that this concept already existed even inthe full stack framework as libs are integrated a 2 levels : bridges(component level), and bundles.
  • 20. From Symfony components to full stackvendredi 30 novembre 12So yes, we had our wheel.But compared to what we could have...So why don’t we simply use and extend main Symfony bundles ? Because it’s«not invented here» ? Let’s be serious.So we took the decision to go for Symfony full stack.Another decision we made was not to put everything in bundles, to be asdecoupled as possible, at least from the full stack framework, to keep ourindependency. We actually realized that this concept already existed even inthe full stack framework as libs are integrated a 2 levels : bridges(component level), and bundles.
  • 21. Cross communities We all have something to sharevendredi 30 novembre 12I can hear some of you saying «Hey, you just copied what Drupal guys did!»or «But what about Symfony CMF ?»We obviously share the same goal : Make our PHP applications the bestpossible. Why couldn’t we share the same tools ?Drupal/eZ Publish : Of course we are in competition for many projects. Butit’s a sane competition now, because we have something in common, so weneed to collaborate. And we already did ! Helping each other on IRC,discussing on Symfony CMF pull requests... It creates an emulation, and nowwe can really focus on features that make the difference between thedifferent systems available.
  • 22. Now we’re part of the Symfony family But not only...vendredi 30 novembre 12And we thus already started to contribute (through Symfony CMF, some PRon Symfony main repository)Not limited to the Symfony family. Don’t forget that eZ Publish’s corebusiness logic resides in its API, which can be virtually ported to anyframework. Why not imagine a port to work with ZF2 for instance ?
  • 23. Fin Twitter : @jvieilledent https://joind.in/7563 http://github.com/lolautruche http://share.ez.no/community/profile/11256 21vendredi 30 novembre 12