Symfony and eZ Publish

Symfony'and'eZ'PublishLet’s&have&a&trip&together

Jérôme Vieilledent - Software engineer / http://ez.no / http://share.ez.no

vendredi 30 novembre 12

http://ez.no

http://ez.no

http://share.ez.no

http://share.ez.no

Genesis of the Symfony aspects


eZ 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 code kept unchanged.

Several attempts were initiated for a complete rewrite (back in 2008 with eZ Components) but the real project began in mid-2010 with a complete re-thinking of our core business API.

Requirements

• Easily integrate our API

• HMVC (Hierarchical Model View Controller) stack

• Decoupled components

• Dependency injection

• New template engine

• Extensible, Open, Reliable ;-)


API : Working on it for more than a year at that time. Complete rewrite of what makes our core business logic. It’s using DI, but without any container or any dependency from out there. Completely independentHMVC : In our old model we kind of used MVC, but flawed by too much logic in the view (fetch functions). We needed something that fixes both our needs (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 easily switch from one engine to another.

Get rid of the (old) monolith


And of course our approach was monolithic (legacy PHP 4 ages, weak OO model).Lots of extension points, but interdependent, impossible to decouple, impossible to test properly (singletons everywhere)

Useful things start in a bar


Lisbon conference, almost all eZ engineering, in an informal beer meeting (probably the best way to make meetings ever). Community guys were here too. We became to chat about what would be eZ Publish 5 (after some more beers, so that we were too drunk to fight).Sharing one’s experiences with Twig, Symfony2, Zeta... We started to imagine how would the paper gift around eZ Publish API would be

Options

• Home made

• Zeta Components

• Zend Framework 2

• Symfony 2


Home made : Why would we do that ? Too much work for what ? Doing the same mistakes than in the past, just because otherwise it would be «not invented here» ? NoZeta Components : eZ has a long story with them. Back in 2008-2009, their destiny was to become the next generation of eZ Publish. For several reasons it didn’t happen. And to be pragmatic, it would have been a lot of work to adapt them to work with DI or HMVCZF2 : Still immature at that timeThen Symfony2 looked as an obvious and reasonnable choice. Furthermore it’s heavily used, has a very active and nice community, and easy to learn. Let’s do it !

Backwards Compatibility

*Knock knock*

devs: «Who's there ?»«Product Management»

devs: «Product Management who ?»«PM who wants to talk about BC»

devs: «Oh crap...»


Then the trouble began. We could have picked any other choice, the same problem would have come anyway.

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 modules


Data compatible : The most important. One can easily switch from a legacy eZ Publish 4.x instance to 5.0

BC: The challenge


BC: The challenge

PM SCRUM Story:

«As an eZ Publish user, I don’t want to be pissed off by a new #@!$% version!»


eZ Publish 3 use case (2003). Major change => eZ Publish lost the 2/3rd of its users, community members... Because there was no BC at all.

BC: The challenge

Challenge accepted


Obviously 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 when Symfony 2 came out, to make their Symfony 1 application work with it.

BC: The challenge

Sandbox Legacy code

...in a \Closure !


Code speaks like a thousand words

BC: The challenge


So yes of course, we needed to refactor a lot the old kernel (esp. the old front index.php and reduce it from 1.000+ lines to a dozen.Using runCallback, legacy code is completely isolated. We can keep high cohesion and loose coupling. Of course it adds some overhead, but it’s fairly minimal from what it represents.

This is the central feature on top of which we built all the requirements asked. And guess what ? It works !

BC: The Architecture


BC: Icing on the cake

eZ Publish legacy still works independently !


From Symfony components to Full Stack


When we started to do some prototyping, we needed to dive deep into the Symfony components, to understand how they work together. We also needed to be sure that they were loosely coupled.So we started to use only some of them + Twig

From Symfony components to full stack

• HttpFoundation

• HttpKernel

• Routing

• Dependency Injection

• Bundles

• Templating + Twig

• Composer


The more we moved forward, the more our prototype looked like Symfony standard edition.Of course we started our own glue to tie these components together, in our own bundles. But we found out that we were doing exactly the same than in base Symfony bundles (but not that good, because not that generic).

From Symfony components to full stack


So 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 as decoupled as possible, at least from the full stack framework, to keep our independency. We actually realized that this concept already existed even in the full stack framework as libs are integrated a 2 levels : bridges (component level), and bundles.

Cross communities

We all have something to share


I 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 best possible. Why couldn’t we share the same tools ?Drupal/eZ Publish : Of course we are in competition for many projects. But it’s a sane competition now, because we have something in common, so we need to collaborate. And we already did ! Helping each other on IRC, discussing on Symfony CMF pull requests... It creates an emulation, and now we can really focus on features that make the difference between the different systems available.

Now we’re part of the Symfony family

But not only...


And we thus already started to contribute (through Symfony CMF, some PR on Symfony main repository)

Not limited to the Symfony family. Don’t forget that eZ Publish’s core business logic resides in its API, which can be virtually ported to any framework. Why not imagine a port to work with ZF2 for instance ?

21

Fin

Twitter : @jvieilledenthttps://joind.in/7563

http://github.com/lolautruchehttp://share.ez.no/community/profile/11256


https://joind.in/6461

https://joind.in/6461

http://github.com/lolautruche

http://github.com/lolautruche

http://share.ez.no/community/profile/11256

http://share.ez.no/community/profile/11256

Symfony and eZ Publish

Technology

Transcript of Symfony and eZ Publish