eZ Community » Forums » Discussions » eZ Publish 5 from a technical point...
expandshrink

Tuesday 10 July 2012 2:52:03 pm - 21 replies

» Read full blog post

Introduction

The "Why" and how BC will not kill you

Last week we announced the new synergy between the upcoming eZ Publish 5 and Symfony 2. A lot of technical questions naturally popped out and eZ Engineering will try to address answers to most of them in a series of blog posts, this one being dedicated to our choice and backwards compatibility.

EDITThe next episode of the story is available:  eZ Publish 5 from a technical point of view, Part 2

Wednesday 11 July 2012 11:36:02 am

Thanks for this very interesting blog post ! 

The sandboxed execution of legacy API is purely awesome happy.gif Emoticon 

What about caching, are you planning to use the same logic as the legacy stale cache or do you plan to use Symfony HTTP cache component ?

Will it be possible to use Symfony HTTP cache as a first layer for forwarded to legacy requests ?

About clustering, I guess eZ DFS mode will still be compatible thanks to forwarding but do you plan to develop a similar solution on eZ 5 ?

Wednesday 11 July 2012 12:12:06 pm

Quote from Matthieu Sévère :

The sandboxed execution of legacy API is purely awesome happy.gif Emoticon

Thanks, I know you would loved it happy.gif Emoticon.

Quote from Matthieu Sévère :

What about caching, are you planning to use the same logic as the legacy stale cache or do you plan to use Symfony HTTP cache component ?

We are clearly going to use the HTTP cache component, but we probably won't stop here. We indeed need more cache levels, especially when it comes to runtime configuration (like for siteaccesses).

Quote from Matthieu Sévère :

About clustering, I guess eZ DFS mode will still be compatible thanks to forwarding but do you plan to develop a similar solution on eZ 5 ?

We actually developed an IO service in the public API. This service makes use of the legacy cluster features in the background by default, but that will also allow to use new implementations (i.e. Amazon S3, Akamai...).

Wednesday 11 July 2012 4:00:01 pm

Hi Jérôme,

Thanks for sharing this details, very interesting happy.gif Emoticon

One question : when you mean 10/15ms per request, if a page is complex and is build with many (ajax) requests, it can start to be quite annoying at the end. I think also that it's only for the 1st generation. With cache, the extra costs should be "absorbed".

Correct ?

Wednesday 11 July 2012 4:13:11 pm

Interesting post.
But every time I read about eZ 5, I can't help thinking to anything else than a bloatware.
Let's summarize what eZ 5 is using:
- 2 underlying frameworks:
  - eZ/Zeta Components
  - Symfony 2
- 2 templates engines:
  - eZ 4 template engine
  - Twig
 
I have the feeling that making eZ so complex (not complicated) will result in a slow learning curve and not help new developpers to enter the community.
And beside the performance impact, it can lead to twice potential security issues.
If you have a look at the competition, eg Typo 3, there is one framework and one template system.
 
It is also worth to note that for a newcomer, eZ 4 as it is, feels already quite bloated and obscure.
For example, settings files that can be in the global default, global override, global siteaccess, extension default, extension siteaccess and quite the same thing can be said for templates and templates overrides.
I can understand the full compatibility argument, but not if it cost on learning, simplicity of development and debugging.
I really hope eZ 5 will have what eZ 4 never had, an up-to-date and detailed documentation because having such a big & complex code base will make the "no docs, let's check the code" option not realistic anymore.

Wednesday 11 July 2012 4:30:15 pm

Quote from Nicolas Steinmetz :

Hi Jérôme,

Thanks for sharing this details, very interesting happy.gif Emoticon

One question : when you mean 10/15ms per request, if a page is complex and is build with many (ajax) requests, it can start to be quite annoying at the end. I think also that it's only for the 1st generation. With cache, the extra costs should be "absorbed".

Correct ?

Indeed, the extra costs will be absorbed by the HTTP Cache layer (+ legacy cache eventually)

Wednesday 11 July 2012 5:38:44 pm

 

Quote from Eric Sagnes :

But every time I read about eZ 5, I can't help thinking to anything else than a bloatware. 

Don't you exaggerate a bit ? blunk.gif Emoticon

I mean, would you have liked a complete shift without any BC ? I don't think so... The presence of the legacy kernel (including eZ Template engine) is only for compatibility purpose and will be less and less used.

We don't enforce using the legacy template engine or legacy kernel features. Of course, not everything is implemented yet but we're going forward in order to have as least complexity as possible. And by the way, there is only 1 framework, not 2 ! The only framework that is used is Symfony. The rest are libraries, as can be other bundles that we could use from the Symfony community to improve eZ Publish (I'm thinking here about Assetic, or even PHPCR).

Of course BC has a cost in the term of complexity, but it will decrease through time as everything will be rewritten within the new architecture, but the learning curve should not be (and won't be) as hard as it was before, since there are a lots of resources talking about Symfony out there, a very good documentation for the basics, and we will provide extensive doc on eZ specific features.

Wednesday 11 July 2012 5:55:07 pm

Quote from Eric Sagnes :

Interesting post.
But every time I read about eZ 5, I can't help thinking to anything else than a bloatware.

I think you have missunderstood some parts: there are two stacks. We are building a new pure 5.x stack that aims at simplifying the learning curve a lot, and at the same time being a solid foundation for the future in the form of:

  1. Public API: being ready for all kind of cache solutions, all kind of database solutions, all kind of file storing solutions and being scalable, but also simplify the terminology and make our API's highly documented.
  2. The whole eZ Publish 5 stack including Symfony based web stack: Using existing technologies that people are familiar with, supported by IDE's, has a large community backing and so on
  3. REST API: Expose everything in Public API also over REST API, enabling a new wave of ajax and advance clients on top of eZ Publish

The reason why the existing eZ Publish 4.x is there as well is to provide 100% straight upgrade path, it doesn't mean that you are supposed to mix both parts when you at some point is ready to create a new website on top of the 5.x stack, this is there so you can upgrade an existing website without any hassle, and then optionally do the work on getting it over to the 5.x stack step by step. 
Since you bring forward Typo3, the parallel is very similar, they are also in the middle of rewriting their core parts, but instead of using existing frameworks they have created flow3 and have used 3-4 years on that already restarting the approach several times.

Wednesday 11 July 2012 6:22:16 pm

Good work guys, keep it rolling!

Wednesday 11 July 2012 6:37:59 pm

Quote from André R :
Quote from Eric Sagnes :

Since you bring forward Typo3, the parallel is very similar, they are also in the middle of rewriting their core parts, but instead of using existing frameworks they have created flow3 and have used 3-4 years on that already restarting the approach several times.

I don't want to sound rude, but I think that applies as well to decisions made in the past (timeframe 2006 - 2009) regarding eZ Publish & eZ Components, which at a certain point were supposed to be the building blocks for the next generation of eZ Publish happy.gif Emoticon But we'll see how much of the eZ Components will eventually end up being used in eZ Publish 5 (or 6) and which will eventually stay unused or get dropped from core.

Wednesday 11 July 2012 9:37:10 pm

Quote from Kristof Coomans :

I don't want to sound rude, but I think that applies as well to decisions made in the past (timeframe 2006 - 2009) regarding eZ Publish & eZ Components, which at a certain point were supposed to be the building blocks for the next generation of eZ Publish happy.gif Emoticon But we'll see how much of the eZ Components will eventually end up being used in eZ Publish 5 (or 6) and which will eventually stay unused or get dropped from core.

Rude => Precise happy.gif Emoticon

I was simplifying a bit, anyone that has followed eZ for the some years know that there has been plans for larger changes since back when eZ Components was started. But in the end given the changes in the market, PHP and PHP ecosystem, adaptation of things like Dependency Injection Container and the popularity/support of Twig and Symfony made use realize that we should reuse instead of spending time on getting all Components we need up-to-date.

As mentioned by Jérôme we continue to use some of them though, on top of those already in 4.x we use ezcDB while we probably could have used Doctrine DBAL, and ezcCache for instance is a good candidate for cache handling. And those we use, we intend to contribute to.

To me personally however, the aim for eZ Publish 5 is first and foremost to make sure we have a architecture that will be able to last for the next 10 years and beyond. Which imho might mean we should try to abstract any use of Symfony in controllers and other core extension points, as frameworks seems to have a life span of 5 years in the PHP ecosystem before they are rewritten or replaced.
But at the same time we want to make sure Symfony Bundles can work with eZ Publish 5, so if we do this abstraction it needs to be opt in. 

Modified on Wednesday 11 July 2012 9:39:27 pm by André R

Wednesday 11 July 2012 11:37:53 pm

Quote from Eric Sagnes :

It is also worth to note that for a newcomer, eZ 4 as it is, feels already quite bloated and obscure.
For example, settings files that can be in the global default, global override, global siteaccess, extension default, extension siteaccess and quite the same thing can be said for templates and templates overrides.

I think a lot of the complexity in the ini system stems from having to maintain BC with much older eZ systems. From the looks of it originally the developers intended eZ to be configurable from the admin interface: ini files, templates, overrides are all editable via the back end. Unfortunately at some point someone decided to shift towards plain text ini files, but nobody ever got around to getting rid of the original stuff. My vote would be to make as much as possible text file based, including the workflows, roles etc. I find it frustrating that roles can't be readily exported and dropped into a different instance of eZ.

A plain text (XML) import/export of content classes would be nice too. Will eZ be going to the 'basic object, extended to create more complex ones' model, rather than the current 'build content classes from scratch' model?

Quote from Eric Sagnes :

I really hope eZ 5 will have what eZ 4 never had, an up-to-date and detailed documentation because having such a big & complex code base will make the "no docs, let's check the code" option not realistic anymore.

I haven't really had a problem with the docs, barring that the removal of user comments has effectively strangled user the user input which used to be so handy.

Modified on Thursday 12 July 2012 12:04:17 am by Jérôme Vieilledent

Friday 13 July 2012 9:25:00 am

Hello

Using symfony as the underlayer framework is really a great news

I'm looking forward to go back to eZ business!

Friday 13 July 2012 5:47:47 pm

Regarding a complete migration from eZ Publish 4 to eZ Publish 5, I think the best approach is to do it successively: module by module (to controller), view by view (to controller action), template by template (to Twig template). In addition, you can "migrate" each eZ template to a Twig template by using the legacy template support added by eZ at first, and in a second step you can actually migrate it to a "native" Twig template later.

This gist demonstrates how to migrate the plain view of eZ's content module at which you still rely on the legacy templates but not on the legacy module.

Saturday 14 July 2012 12:43:16 am

Impressive work guys!!

 

look forward part 2!

Saturday 14 July 2012 8:31:05 am

Quote from Fabian Kiss :

This gist demonstrates how to migrate the plain view of eZ's content module at which you still rely on the legacy templates but not on the legacy module.

This is an interesting approach, but that might bring too much overhead...

We do plan to migrate progressively, as this is the best way to do, but I don't think we would use the legacy include feature in this way. I'd rather prefer simply forwarding the template matching to the legacy kernel if nothing is matched in the new kernel :

  1. Try to match a Twig template
  2. Use legacy override system if nothing matched

This is still under discussion and this point will probably be addressed in the next couple of weeks. And if you're willing to help, we'd be very glad and would welcome your contribution happily !

Nicolas, along with eZ Engineering, is currently setting up a process for collaboration with the community in feature development happy.gif Emoticon

Wednesday 15 August 2012 6:09:37 pm

What information is there on if the database schema will be changed much? At the moment eZ uses an EAV type schema for content types and content data.  Will that remain in the long-term?  I hope that will remain at least an option.
Any plans for a more flexible DAL to allow for other types of data-store? 

Modified on Wednesday 28 November 2012 6:53:39 pm by Luc Chase

Wednesday 15 August 2012 8:02:00 pm

Hi Luc

There is currently no short term plan to change the database schema, though we can from time to time optimize things like we usually do. In the long term it is of course possible that it will change, but it will probably not happen until version 6 (when we'll completely get rid of the legacy system).

Quote from Luc Chase :

Any plans for a more flexible DAL to allow for other types of data-store? 

Yes, and it will happen thanks to storage engines. Storage engines stand below the public API and it's perfectly possible today to implement a new one, based on PHPCR for example. The only issue is the admin interface because for 5.0 (and probably a couple of other versions), it entirely sits on legacy. But as soon as the admin interface uses the public API, everything will be possible then.

And as of now, it is possible for example to implement a storage engine using Doctrine DBAL, allowing to have an implementation of Oracle client for instance (which is not possible yet with current legacy storage engine).

Thursday 16 August 2012 12:21:52 pm

Quote from Jérôme Vieilledent :

In the long term it is of course possible that it will change, but it will probably not happen until version 6 (when we'll completely get rid of the legacy system).

Correction: It can be done before, but in a new storage engine where you skip legacy bc.

@Luc: Potential plan for doing this is to #1 refactor Core\Persistence\Legacy to use Doctrine DBAL instead, and #2 branch of a new persistence storage engine where the database schama is heavily improved. I'm not sure when we are able to do that though, probably after 5.1. If your interested in helping out, let us know, we can for instance start the specification process for such a storage engine way before 5.1!

Modified on Thursday 16 August 2012 12:22:42 pm by André R

Saturday 25 August 2012 12:13:47 am

@Paul Bolger

I think much of the complexity of the current ini system comes from wanting to be 100% legacy-compatible, but in a slightly different sense: being compatible with existing eZ implementations in terms of loading order and scope.

The current ini system is not flawed because of its dual text-file/gui nature, it is flawed because:

- it conflates scope (per-siteaccess settings vs. global settings) with priority

- it does not allow a siteaccess to easily inherit most settings from another one (like templates do)

- it gets priorities wrong (siteaccess settings lower than extension settings)

I agree that eZ should have better import/export facilities for everything which is stored in the db, from workflow definitions, to roles and policies, to

But the problem here is not really about defining a format for those data (using xml would be trivial), it is rather dealing with the complexity of "updates" rather than "creations", eg. being able to stage content-class definition changes and deploy them from staging to prod servers when there is existing content.

Last but not least: while the template fallback and override systems give a great deal of flexibility, they are also a nightmare in terms of support - introducing dependencies everywhere and making them impossible to track. I once proposed to do away completely with override.ini and only allow simple overrides (based on class or node id), but the idea did not seem to gain much traction.

Short of that, nicer gui/scripts that ease finding which templates are used in a page, and which pages are used by a template, are a much welcome enhancement.

@all the rest - sorry if this comment looks off topic. I just wanted to repeat here some of the concepts which I think are important to get right when we reimplement them in ezp5. We don't have just to write better code thanks to improved oop patterns and components, we have to learn from our past mistakes and avoid repeating them.

Wednesday 12 June 2013 5:20:59 pm

"See fully functional example in the eZ Publish 5 DemoBundle (take a look at the associated controller as well)."

Second link is dead.

expandshrink

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

36 542 Users on board!

Forums menu

Proudly Developed with from