Symfony and eZ Publish

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

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 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.

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 ﬁght).
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» ? 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 !

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 ﬁt 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 ?

Fin

Twitter : @jvieilledent
https://joind.in/7563
http://github.com/lolautruche
http://share.ez.no/community/profile/11256
21


Symfony and eZ Publish

More Related Content

What's hot

Viewers also liked

Similar to Symfony and eZ Publish

Recently uploaded

Symfony and eZ Publish