blog post reposted from https://www.ezplatform.com/Blog/eZ-Platform-Version-2-Is-Shaping-Up-and-Getting-Simplified 

This blog has been quite silent lately. It’s not that there wasn’t anything to discuss, but more that we were too busy. At the end of August we announced 1.11 (see 1.11 release notes) and, maybe more importantly, we also announced the official support for the legacy bridge and a new version of the legacy eZ Publish (more info here).

However, the most important thing we’ve been working on is of course, the version 2 of eZ Platform. As you may know we announced the first alpha versions of version 2 back in June, around the time of the last eZ Conference. While we were happy with the early prototypes and first alpha versions in many respects, we also had some concerns, which led us to change quite a few things in what will be eZ Platform 2 in the end. Let me give you some insights on those changes.

The changes we made since the alpha are purely on the U.I. architecture side. Our initial exploration and prototypes led us to an architecture in the alpha version that we called “hybrid U.I.” and that I summarize as:

  • Much more based on Symfony (application routing being done with Symfony and front-end being developed with Symfony as a main option)
  • Still using a single page application paradigm (using the PJax system to (re)load part of the application from Symfony without reloading “the page”)
  • With the decision of reusing some parts of the previous version (based on YUI), embedding them in some custom tag, relying on Web Components and the Polymer library for that (the reasoning behind this was assumption that we would not have the ability to re-develop all parts and that some parts were absolutely satisfactory)

When we reached the alpha version, and began to move forward targeting a beta, we started to have more developers looking at it and developing on top of it—developers from eZ Systems, but also external developers willing to test or contribute to version v2.

We realized that, for a new developer, the application remained complex to apprehend and understand, and that this was probably not helping to “accelerate the development” enough (one of the top requirements), as much for eZ Systems’ teams working on it as for partners and customers who would work to extend it. Our observation was that it also brought additional complexity that would make it more difficult to build a solid and robust application.

We observed that allowing a progressive removal of the YUI-based part by having Web Components wrapping YUI had drawbacks (need to always load YUI, complexity, inability to simply enhance in the future) that were questioning our initial assumptions.

So we looked into taking a simpler and more pragmatic approach, that I summarize with the following changes:

  • Making it a “pure” Symfony application. The hybrid U.I. was a Symfony application, but having an additional layer of logic to make it “SPA-like” was not making it a “pure” Symfony application. This means not using the “pjax” dynamic loading of the application parts within the page but simply using a classic http page reload in most cases, just like in the average Symfony application.
  • Still offering the ability for developers to build parts (or widgets) that would be highly interactive and dynamic, based on JS, and that could behave without page reloads, but in a simpler and lighter way and without ever making this a core part of the architecture.
  • Not reusing and carrying with us YUI-based code, hence rewriting all components we had that were still using YUI, instead using Symfony and React (such as the Universal Discovery Widget, the Sub-items Widgets and after that, the Landing Page Editor).
  • Also using React.js for any future part of the application that might need advanced U.I. capabilities.

And that proved to be a good route, especially with the performance bump offered by PHP 7. With this choice we are confident we can offer a good and very fast user experience, if not better. More importantly, we think we can have a more effective way for developers to understand and develop on the platform and build stable and solid features more quickly. This should pay off even in the initial development cycle, as we reach beta and stable stages more quickly with this approach. From there, we will be able to iterate more quickly on the rich components as well, now that they are pure React.js and not abstracted within web components.

This might seem to be a significant change at this stage. It’s however not a revolution, it’s more of an internal refactoring. Most of the U.I. components that have been developed in hybrid U.I. previously (based on Pjax) can be easily adapted without re-coding them, and have been re-used. So if you started to explore extending hybrid platform U.I. alpha with Symfony, your development should also adapt very easily to this new approach. And of course, under the skin of the interface, all things remained unchanged, and when it comes to U.I. and U.X. design, things remain largely unchanged besides the fact that the U.I. guidelines will have to provide front-end HTML and CSS snippets that will fit with this new approach—we already started to work on that.

At the current stage we are working towards releasing a Beta version of eZ Platform Version 2 based on this updated U.I. architecture by end of October and still targeting a stable version by year-end with one single component still embedding some YUI code—the landing page editor from Studio. So far we’ve worked in personal repositories in development stage but are cleaning up and reorganizing the code in the final public repositories under eZ Systems Github organization (https://github.com/ezsystems/ezplatform-admin-ui for the main application and https://github.com/ezsystems/ezplatform-admin-ui-modules for the widgets developed with React.js).

We hope you’ll like this change, we think Symfony developers should find it much more welcoming, making their life simpler and helping them to get things done faster. Which after all, was the original request from partners and the community. In the future, we’ll keep this route of trying to further simplify the architecture, making Symfony the only core dependency that a developer should know to develop quickly with eZ Platform. JS developers will still be welcomed, extending both the Platform U.I. or the front-end of their sites with highly interactive capabilities, without being a core requirement.

Please feel free to leave your comments below this post.

Load Comments
loading...