1. Symfony'and'eZ'Publish
Let’s&have&a&trip&together
Jérôme Vieilledent - Software engineer / http://ez.no / http://share.ez.no
vendredi 30 novembre 12

2. Genesis of the Symfony aspects
vendredi 30 novembre 12
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.

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 12
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 independent
HMVC : 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 model
Decoupled + 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.

4. Get rid of the (old) monolith
vendredi 30 novembre 12
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)

5. Get rid of the (old) monolith
vendredi 30 novembre 12
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)

6. Useful things start in a bar
vendredi 30 novembre 12
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

7. Options
• Home made
• Zeta Components
• Zend Framework 2
• Symfony 2
vendredi 30 novembre 12
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» ? No
Zeta 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 HMVC
ZF2 : Still immature at that time
Then 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 !

8. Backwards Compatibility
*Knock knock*
devs: «Who's there ?»
«Product Management»
devs: «Product Management who ?»
«PM who wants to talk about BC»
devs: «Oh crap...»
vendredi 30 novembre 12
Then the trouble began. We could have picked any other choice, the same
problem 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 modules
vendredi 30 novembre 12
Data compatible : The most important. One can easily switch from a legacy
eZ Publish 4.x instance to 5.0

10. BC: The challenge
vendredi 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 12
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.

12. BC: The challenge
Challenge accepted
vendredi 30 novembre 12
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.

13. BC: The challenge
Sandbox Legacy code
...in a Closure !
vendredi 30 novembre 12
Code speaks like a thousand words

14. BC: The challenge
vendredi 30 novembre 12
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 !

15. BC: The Architecture
vendredi 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 Stack
vendredi 30 novembre 12
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

18. From Symfony components to full stack
• HttpFoundation
• HttpKernel
• Routing
• Dependency Injection
• Bundles
• Templating + Twig
• Composer
vendredi 30 novembre 12
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).

19. From Symfony components to full stack
vendredi 30 novembre 12
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.

20. From Symfony components to full stack
vendredi 30 novembre 12
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.

21. Cross communities
We all have something to share
vendredi 30 novembre 12
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.

22. Now we’re part of the Symfony family
But not only...
vendredi 30 novembre 12
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 ?

23. Fin
Twitter : @jvieilledent
https://joind.in/7563
http://github.com/lolautruche
http://share.ez.no/community/profile/11256
21
vendredi 30 novembre 12