eZ Community » Forums » Discussions » An explosive cocktail : Symfony and...
expandshrink

Monday 02 July 2012 12:05:25 pm - 68 replies

» Read full blog post

Introduction

Ever dreamt of an even more powerful eZ Publish?
Ever dreamt of an even more flexible eZ Publish?
Ever dreamt of an even easier to learn eZ Publish?

 
Well...you’d better read on.

 

Thursday 05 July 2012 10:50:51 am

Hi Eirik

As for Siteaccesses, we already started as you can see it on GitHub. The matching is triggered in the main router. The main idea is to have a SiteAccess object held as a Request attribute (and probably accessible from anywhere via a dedicated service). Once matched, we need to fix up the URI if needed (basically remove the siteaccess part from the URI if applicable).

From there on, we're gonna need to load siteaccess specific configuration on the fly. This is the part we're currently stuck on because Symfony doesn't allow to load DIC configuration out of the box, so we'll most likely use our own logic here and add a cache layer (probably using ezcCache).

As for design override, we didn't reach this step yet, but we'll come with proposals soonish. And we probably won't use bundle inheritance for that.

Thursday 05 July 2012 11:02:15 am

Hi friends,

I am surprised to see that this blog post hasn’t caused more discussion within the community. I have looked at Sympfony the past few days, and it does look like a very solid framework to build applications upon. However, I have some remarks/questions:

  • I get the impression eZ Publish 5 is just eZ Publish running in a Symfony wrapper. The need for backwards compatibility seems to make it impossible to make full use of the opportunities Symfony offers. But looking at the comments, it also appears that the developers are already aware of this. I get the impression that nobody wants to be the first to say ‘backwards compatibility is not feasible if we want to move ahead’. Giving up on backwards compatibility is painful, as I recall from the change from eZ Publish version 2 to 3. We lost quite a number of dedicated community members, but gained a lot more in the years after. It’s a risk, but maybe we should just give up on backwards compatibility.
  • There are going to be a lot of clients and developers who have invested a considerable amount of time/money in eZ Publish 4 projects. These people are not going to update to eZ Publish 5, just for the sake of having a MVC framework that is basically just a wrapper. The costs of rebuilding their site eZ Publish 5 might be just too high. This means that eZ Publish 4 is going to be around for a long time to come, and people are going to need not only bug fixes, but also improvements, new functionality, etc. In other words, eZ Publish 4 will continue to need a community of very active developers for a long time to come.
  • Correct me if I am wrong, but I get the impression the choice for Symfony has been made very recently. It almost appears as if developers at some point decided that the existing kernel of eZ Publish was not suitable to reach the objectives set, and decided to start all over again on a framework. This would mean that a lot of time has been lost, and makes it unlikely that eZ Publish 5 will be released according to schedule. It seems to me that this was a tech decision, rather than a management decision. And I think that management does not oversee the full consequences of this decision, or it’s a leap of faith forward. I would like to know more about how decision has come about.
  • This brings me to the following question: how many developers are actually working on eZ Publish currently? How many are commited to the further development of eZ Publish 4 and how many are working on eZ Publish 5? Suppose eZ is commited to releasing eZ Publish 5 in time, at any cost? Will this mean that development of eZ Publish 4 will slow down?
  • With regards to development: even with backwards compatibility I suppose we need to become Symfony developers rather than eZ Publish developers. Again, clients and developers may not be willing to make this investment.

My conclusion: drop the backwards compatibility – nobody is going to benefit from this. Fork eZ Publish at this point, to ensure eZ Publish 5 can make full use of the opportunities Symfony offers. Continue development of eZ Publish 4 with a group of people who are happy with the current product, and who do not really need the introduction of a MVC framework.

Looking forward to your comments!

Thursday 05 July 2012 11:02:34 am

 

Quote from David Ennis :

 In fact, regardless of the task being done sooner rather than later, templates, extensions, modules, custom fetches, custom template operators will ALL have to be re-programmed/re-factored for complete representation in EZP5. Maybe not soon, but certainly something that will require a budget as there is no true upgrade path from eZP4 to eZP5 other than re-write most of what you have. 

This is precisely what made me write this blog post about preparing for the future. Of course, at some point you will have to rewrite stuff, but BC gives you some time to do it in a smoother way, rather than rewrite everything at once. We'll rely on eZP4 for something like 2 years from the first 5.x release, so take benefit of this period.

For everything else regarding BC, I'll write a blog post soonish about that, for clarification happy.gif Emoticon

Thursday 05 July 2012 11:24:41 am

To be a bit blunt, Sebastiaan, if you had checked what was published (even though it was not enough), you'd have seen how backward compatibility has been approached.

Backwards compatibility is NOT an option, it is something we WILL provide and HAVE worked on already. And to be honest: Symfony has almost nothing to do with backwards compatibility in our new architecture. Storage is one aspect of eZ Publish 5, and storage has been decoupled so that the old content (database + files) can be used as is, without the need for any data migration.

eZ Publish 5 also wraps eZ Publish 4, that is true, through conditional routing. It also makes it possible to run eZ Publish 4 templates, and to run eZ Publish 4 modules.

So yes, we have placed limits to how backward compatible we have, because we do know full compatibility is pointless.

And yes, eZ Publish 5 is and will be our main focus from now on. Innovation on eZ Publish 4 can continue through the eZ Market (and it is starting to grow into interesting proportions), as well as through community contributions, and will be maintained by eZ Systems according to the terms of our Enterprise offer. It is as simple as that.

Modified on Thursday 05 July 2012 11:28:06 am by Bertrand Dunogier

Thursday 05 July 2012 11:29:42 am

 

Of course, at some point you will have to rewrite stuff, but BC gives you some time to do it in a smoother way, rather than rewrite everything at once. We'll rely on eZP4 for something like 2 years from the first 5.x release, so take benefit of this period.

 

Agin, this is great and commendable that there is any transition period at all with such a major shift. But wether the bill is paid by a client upfront (a single major transition) or over a two year period, at some point you will have to rewrite stuff, so a (not so small) budget will need to be allocated to the tune of possibly tens of thousands.
Put this into an some fantasy best-case scenereo from a  financial point of view  2 year migration with quarterly milestones and 20Kbudget for full migration. I would even plan the transition in a way that the benefits were seen in the first part of migration by introducing some 'bells and whistles' early on. However, I still have the work to do and the invoice to send out.

  • That math still says 2.5k per quarter for 2 years.
  • 2010-2012 - major investment in a website
  • 2013-2014 - somewhat major investment in migrating the website as above

Simply put, I believe that there are some websites that have just gone through a  major overhaul that will end up living out their life in eZP4 as the funds would not be justifiable over the next few years for yet another overhaul.
This is not a hit against eZP5, but just a pragmatic response to the situation -eZP5 will not be for all current websites if there is a large investment needed in the migration - even spread over a few years.  Not a bad thing or a good thing - jut reality as I see it..

Thursday 05 July 2012 12:24:24 pm

Hi Bertrand,

Thanks for your reply. To be a bit blunt too: you going to have to live with the fact that more community members/clients like me will start asking questions like these. Maybe they won't ask you, but they will ask the ez partners. Telling them they haven't done their homework won't do. Don't expect people to go chasing through lists of links to find the answers to their questions. This blog post should have been much more informative: now its mostly explosive because of all the missing info.

Thursday 05 July 2012 12:28:54 pm

 

Quote from S V :

This blog post should have been much more informative: now its mostly explosive because of all the missing info

That's why other blog posts are coming. The first one (mainly about BC) will come next week.

Thursday 05 July 2012 12:43:23 pm

Quote from Bertrand Dunogier :

And yes, eZ Publish 5 is and will be our main focus from now on. Innovation on eZ Publish 4 can continue through the eZ Market (and it is starting to grow into interesting proportions), as well as through community contributions, and will be maintained by eZ Systems according to the terms of our Enterprise offer. It is as simple as that.

The continuing support of eZ Publish 4 and continuing community contributions is great news!

However, with the main focus within the eZ Systems developer pool going towards the 5x branch, is it realistic that 4.x pull requests, code reviews and monthly releases will still be able to be maintained at a relatively stable rate?  Yes, I know there is a level of peer review of other looking at pull requests, but it is my understanding that an internal eZ engineer still has to be involved in the final inclusion of code into the community release.

My fear would be that as time constraints cause more and more pressure on resources that a level of stagnation could develop in the eZ4.x branch due to a bottleneck in the review and release process.

Thursday 05 July 2012 2:31:53 pm

Quote from S V :

Thanks for your reply. To be a bit blunt too: you going to have to live with the fact that more community members/clients like me will start asking questions like these. Maybe they won't ask you, but they will ask the ez partners. Telling them they haven't done their homework won't do. Don't expect people to go chasing through lists of links to find the answers to their questions. This blog post should have been much more informative: now its mostly explosive because of all the missing info.

Where did I say we didn't want those questions, and when did I blamed partners / customers for not doing their homework ? These changes are being presented at every conference we organize for over a year. and we have opened up repositories for feedback. Of course, it is quite obvious that it should have been possible to be more open about what we were doing, but please don't go pretend that we don't listen.

ALL the BC features I have described here exist because we listen to people. You can't on one hand blame us for maintaing BC, and on the other hand blame us for imposing on developers some kind of migration.

@David let's say we'll be agile about that blunk.gif Emoticon
Joke aside, as far as we are concerned, there will be no further release of eZ Publish 4.x. It will of course be maintained, as I've said, and bugs will be fixed the way they currently are. We will also do our best to pull in whatever pull requests, and I don't think the rythm will really diminish during at least the next year. On the other hand, I really hope we will get more and more pull requests for eZ Publish 5, and less for eZ Publish 4 happy.gif Emoticon

Thursday 05 July 2012 2:45:11 pm

@Bertrand: So at which point should I have been aware that Symfony was selected?

Modified on Thursday 05 July 2012 2:49:03 pm by S V

Thursday 05 July 2012 3:04:57 pm

Quote from S V :

@Bertrand: So at which point should I have been aware that Symfony was selected?

When this blog post was written ? happy.gif Emoticon

No seriously, as you've said yourself, the decision wasn't made ages ago. That's also one of the reasons why it wasn't discussed before: there wasn't anything to discuss. We knew we needed a framework, for the basics: MVC, Dependency Injection, Configuration, Templating, and we were almost sure that insisting on building it ourselves was a waste of effort and quality, and a waste of our open-source approach. The final choice of Symfony was a tough one, but as far as I'm concerned, a good one.

But as I've said as well, everything that was done since we started presenting the new architecture, back in september 2011, didn't require Symfony, and still doesn't. It is the Public API with the layered architecture, and it uses a mix of custom code & Zeta components. This is why this choice wasn't made earlier: it wasn't really required.

Thursday 05 July 2012 3:23:17 pm

@Bertrand, @Jérôme: thanks for answering my questions. I don't doubt that your choice for Symfony is a good one, just trying to get a clear understanding what the impact of this will be on my business and clients, from a SWOT point of view.

Modified on Thursday 05 July 2012 3:41:33 pm by S V

Thursday 05 July 2012 3:47:25 pm

Try to take a look at ez publish lib folder and ezc, most of features there were created from scratch and they became difficult to maintain, I mean, internationalization, database abstraction, cache, debug and so on. Documentation for it are nonexistent. I have read it could cause some delay in the ez5 schedule, actually I believe it could make it more feasible, they will not need to create everything, and I believe it's faster to learn how to use symfony than creating its features, plus in the long therm they will not need to care about maintaining a huge part of the code, that means more time to create a solid CMS and a solid framework that reuses another frameworks. The worst that can happens is that symfony gets discontinued, but I believe that will hardly happens in a near future.

Modified on Thursday 05 July 2012 3:49:45 pm by Thiago Campos Viana

Thursday 05 July 2012 4:24:42 pm

Hi everyone and Sebastiaan, 

Objectives

First, thanks all for your remarks, questions and feedback: exchanging on the Symfony + eZ Publish, as well as on the eZ Publish 5 topic was the primary intention behind this blog post, opening the campaign.

The second objective was to crack totally open, for the first time during the development of a major version of eZ Publish, to the entire community, and neighbors.

What for ?

To continue nurturing the big momentum of contributions that have flowed-in in the past 2 years, to eZ Publish and extensions, from all of you guys. The take-away for eZ, and also myself, was that enforcing full Openness & Transparency is the best & only way to foster a solid feeling of belonging to our Community, and make it shine to towards the outside world, in turn benefitting everyone, and not only eZ Systems. The "Meritocracy and Not Democracy" paradigm has settled, and the multiplication by more than 30 of the volume of contributions between 2010 and 2011 is not an anecdotal result : it is a direct consequence of a stronger community, constantly growing and intensifying since 2009.

eZ Publish 5 : perspectives

Let's zero-in on eZ Publish 5 for a second, it is a still fresh, yet already pretty nice story. I just told about the current momentum in our community, and the entire eZ Ecosystem. The growing positive roar from all corners of both partners and customers also attest, on top of the community engagement, to the interest in what is happening with eZ, that experience people create with the company behind eZ Publish. 

Backwards compatibility enforced

We don't want to ruin that. Should we ?

Please come-up with solid arguments if you think we should, I'll take care of taking them down one after the other, happily. Backwards compatibility is the reflection of this strategy within the much-changing product. Yes to continuous refactoring, no to weighing anchor and leaving everyone on the bank, all puzzled.

The technical solution to this was indeed to wrap the legacy kernel ("eZ Publish 4.x"blunk.gif Emoticon within eZ Publish 5, relying on Symfony's bundle system, smart & flexible architecture. This solution found (please delve into the code to grasp every bit of it) brings two major advantages:

  • It creates a natural fallback onto the 4.x features when not (yet) available in 5.x, ensuring a graceful beta-testing process,
  • It does not block the development of the features within eZ Publish 5 at all : isolation is total, and non-intrusive. 

Sounds a bit ideal as an architecture, I also find this puzzling, but so far, so good, it pretty much is.

Not to mention the full backwards compatibility at the data level: the 4.x schema will still function.

eZ Publish 4 is not abandoned

The embedded legacy kernel / version of eZ Publish will still be of some use on the already built projects or those under maintenance. Upgrading to 5.x is made possible (cf above), as the trend of rebuilding one's website every 3 to 5 years is slowly being replaced by a continuous improvement paradigm. In this respect again, easy upgradability between 4.x and 5.x makes total sense.

The decision as to how long the 4.x series will be built and released (under community project, or as maintenance releases in the Enterprise Edition world) is not made yet, but it certainly will be for years. No fear, no anxiety is needed here, eZ also knows how the market works, we strive to do our best to serve these needs, smartly.

About the Symfony choice, and general eZ Publish 5 roadmap timeline considerations

The choice of Symfony is not a "tech decision". It has been considered thoughtfully, carefully, the idea of focusing on our core skills (CMS, CXM - please read the initial announcement which is fairly clear & transparent on this point) led the show. 

Rolling-back in time (yes, anticipation is another key success factor of product management) to October last year, when we showed the first results of the new eZ Publish PHP API, we brought to you the first bit of what the new eZ Publish 5 is : a new architecture, a new PHP API, a new REST API. Bringing this all together required to find the right "glue", the right commodity libraries, the right controlling scheme (be it MVC, HMVC, or anything else that works). We benchmarked several solutions, prototyped and the conclusion was: Symfony. And yes, delegating part of your product to a third-party solution has implications. We humbly tried to list them, and went through a balancing act between the "Re-invent your own wheel and maintain it for several years and take the risk to put off the guys who do not want to learn yet-another-framework from top to bottom" approach, and the open-source & communities way, where we trustfully choose another solution and community to help us, at the self-imposed condition that we work with them, hand-in-hand.

At this time, we met the Symfony leader and Sensio Labs CEO.

And, as a side-note, eZ Publish 5 will also pave the way for a dedicated Editorial Interface. Full focus is put on eZ Publish 5. 

About the dual identity dilemma

It is true that getting one's hands on Symfony will help to leverage most of eZ Publish 5. However, the bulk of what was doable today in ez Publish 4.x, in terms of extensions, will be available through the new PHP API, which is not Symfony, but precisely one of eZ Publish 5's core added-values, what we do best : content management, in a broad sense.

 

Again, thanks for the comments, and I hope that this small post brought some clarity. 

Please let us know if this was the expected type of information, and if this is not enough. This is what I wanted to trigger by opening-up the eZ Publish 5 world early : exchange with you all !
--
Nicolas 

Friday 06 July 2012 1:02:19 am

Great post Nicolas - brings a lot of clarity to this topic.  Anticipating questions & concerns and pro-actively addressing them is definitely the way to go - I would almost upgrade this forum post to a blog post (or edit the blog post itself to provide a link to your comment/post) for more visibility, given that it answers many Qs.

I think there is a need for patience here too (from the Community), as many details are yet to be finalised, and focus on what we can do individually to:

  • keep 4.x rolling on smoothly
  • help ease the process of change to eZP5.

Geoff

Modified on Friday 06 July 2012 1:19:04 am by Geoff Bentley

Friday 06 July 2012 3:21:17 am

Great news ...For symfony developpers.It s Time for me to switch to another business... I spent a long time to master the intricacies of this cms. I still dont understand what is the outline of this move? this is so vague, that I wonder if there's really an Airplane.Several key questions have been raised in previous comments, and unfortunately remain unanswered.no hard feelings.

Modified on Friday 06 July 2012 3:22:55 am by Karnichi Mohamed

Friday 06 July 2012 5:08:15 am

Quote from Karnichi Mohamed :

Great news ...For symfony developpers.It s Time for me to switch to another business... I spent a long time to master the intricacies of this cms.

@Karnichi Mohamed:  I feel your pain of having invested a lot of time into something, and then feel like your skills will become obsolete.

I don't think switching CMSes is the solution though - I can't think of a CMS which doesn't have this problem - just ask Drupal developers, who will be using Symfony in Drupal 8!  

Change is a constant for web developers - and if you're not constantly learning, your skills are going to quickly become obsolete.  The only difference is the rate of change - standards take a long time to evolve, with good reason; whereas applications & technologies built on top are constantly evolving.

I'm stoked to have an excuse to start working with Symfony, as this makes me more valuable as a programmer; moderately excited about learning the eZ Publish REST & Public APIs; and sad for the eventual depreciation in usefulness of the eZP knowledge I've built up over the last 5 years.

But, 4.x will be around for a while, and there is plenty of time to learn & transition.

Friday 06 July 2012 8:57:22 am

Quote from Karnichi Mohamed :

Great news ...For symfony developpers.It s Time for me to switch to another business... I spent a long time to master the intricacies of this cms. I still dont understand what is the outline of this move? this is so vague, that I wonder if there's really an Airplane.Several key questions have been raised in previous comments, and unfortunately remain unanswered.no hard feelings.

Salut Mohamed,

All you have learned in the past years, all of the experience you have accumulated (and I know you are part of the very experienced ones), all the love you gave to make it your prominent business weapon, shall not be lost.

eZ Publish 4.x will stay, embedded within eZ Publish 5.x, replaced progressively. The reason is to give enough time to the eZ Community to get into the new plane, and learn how to pilot it. Opening-up early, as it was just done, leaves a fairly large room for anticipation on learning both the basics of Symfony.

The move towards a new architecture, a new PHP API, new REST API and a new "glue" between these components was a necessary one. eZ Publish 4's monolithic architecture had to go, had to be refreshed so we all, eZ Publish developers, can continue using it in the large-scale projects, extend it massively to build whole business applications on top of it, at an ever-increasing project delivery speed, be it internally at large companies, or at small agencies. This is what eZ Publish 5 will bring, also now empowered with Symfony.

eZ Publish's fundamental concepts won't be disrupted. The base terminology, the common cultural codes, the content management functionalities : everything stays Mohamed. Instantly recycled & re-used. You are not losing anything here, just put your first foot on the plane, there's a nice party aboard, and you won't get air-sick.

Also please : drop your questions on the topic, we will happily thoroughly answer them.

Cheers,

Modified on Friday 06 July 2012 8:59:20 am by Nicolas Pastorino

Friday 06 July 2012 9:07:16 am

Quote from Geoff Bentley :

Great post Nicolas - brings a lot of clarity to this topic.  Anticipating questions & concerns and pro-actively addressing them is definitely the way to go - I would almost upgrade this forum post to a blog post (or edit the blog post itself to provide a link to your comment/post) for more visibility, given that it answers many Qs.

I think there is a need for patience here too (from the Community), as many details are yet to be finalised, and focus on what we can do individually to:

  • keep 4.x rolling on smoothly
  • help ease the process of change to eZP5.

Geoff

Hello Geoff and thanks !

I just followed your advice and promoted the comment through a link in the the initial blog post. 

Cheers !

Modified on Friday 06 July 2012 9:10:09 am by Nicolas Pastorino

Friday 06 July 2012 12:47:31 pm

Another question: with regards to extension development (new/existing), what's the best approach at this point? Continue in 4.x, rework in 5 or temp freeze?

expandshrink

You must be logged in to post messages in this topic!

36 542 Users on board!

Forums menu

Proudly Developed with from