eZ Platform Version 2 Is Shaping Up and Getting Simplified

­Ce blog a été assez silencieux ces derniers temps. Non pas que nous n'avions rien à dire mais plutôt que nous étions trop occupés. A la fin du mois d'août nous avons annoncé la 1.11 (cf l'article sur la sortie de la 1.11) et, peut-être plus important encore nous avons aussi annoncé le support officiel pour le legacy bridge et une nouvelle version d'eZ Publish legacy (plus d'infos ici).

Quoi qu'il en soit la chose la plus importante sur laquelle nous ayons travaillée est bien sur, la version 2 d'eZ Platform. Comme vous devez le savoir nous avons annoncé les premières versions alpha de la version 2 en juin lors de la dernière Conférence eZ. Alors que nous étions satisfait des premiers prototypes et des premières versions alpha à bien des égards, nous avons aussi eu certaines inquiètudes ce qui nous a amené à modifier un certain nombre de choses sur ce qui sera finalement la version 2 d'eZ Platform. Laissez-moi vous donner quelques idées de ces changements.

Les changements que nous avons fait depuis l'alpha sont purement du côté de l'architecture U.I. Notre exploration initiale et nos prototypes nous ont conduit à une architecture dans la version alpha que nous avons appelé « hybrid U.I » et que je résume comme suit :

• Davantage basé sur Symfony (le routage d'application étant fait sur Symfony et le front-end développé avec Symfony comme option principale)
• Utilisant un paradigme d'application d'une seule page (via le système PJax pour (re)charger une partie de l'application depuis Symfony sans recharger « la page »)
• Avec la décision de réutiliser certaines parties de la version précédente (basée sur YUI), de les intégrer dans une balise personnalisée, en s'appuyant sur les Web Components et sur la bibliothèque Polymer pour cela (le raisonnement derrière cela était l'hypothèse que nous n'aurions pas la capacité de re-développer toutes les parties et que toutes les parties étaient absolument satisfaisantes)

Lorsque nous avons atteint la version alpha et que nous avions commencé à cibler une version bêta, nous avons commencé avec davantage de développeurs à l'observer et la développer. Les développeurs d'eZ Systems mais aussi des développeurs externes souhaitant tester ou contribuer à la v2.

Nous avons réalisé que, pour un nouveau développeur, l'application restait complexe à appréhender et à comprendre et que cela ne contribuait probablement pas à « accélérer le développement » (l'une des principales exigences), autant pour les équipes d'eZ Systems qui y travaillent que pour les partenaires et les clients qui travailleraient à l'étendre. Notre observation était aussi que ceci apporterait également une complexité supplémentaire qui rendrait plus difficile la construction d'une application solide et robuste.

Nous avons observé que le fait de permettre une suppression progressive de la partie basée sur l'YUI en ayant les Web Components enveloppant les YUI, présentait des inconvénients (nécessité de toujours charger YUI, la complexité, l'incapacité à simplement améliorer dans le futur) qui remettaient en question nos hypothèses initiales.

Nous avons donc cherché à adopter une approche plus simple et plus pragmatique, que je résume avec les changements suivants :

• En faire une application « pure » Symfony. L'U.I hybride était une application Symfony mais avoir une couche supplémentaire pour le rendre « SPA-like » n'en faisait pas une application « pure » Symfony. Ceci signifie ne pas utiliser le chargement dynamique « pjax » pour la partie application mais simplement utiliser un rechargement de page http classique dans la plupart des cas, comme dans une application Symfony moyenne.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.
• Toujours pouvoir offrir la possibilité aux développeurs de créer des composants (ou widgets) hautement interactifs et dynamiques, basés sur JS, qui pourraient se comporter sans rechargements de page mais de manière plus simple et plus légère et sans jamais en faire un élément central d'architecture.
• Ne pas réutiliser et transporter avec nous les codes basés sur YUI, réécrivant ainsi tous les composants qui utilisaient encore YUI, utilisant plutôt Symfony et React (comme l'Universal Discovery Widget, le Sub-items Widgets et après cela l'éditeur de Landing Page).
• Utiliser également React.js pour toute partie future de l'application qui pourrait avoir besoin de fonctionnalités d'U.I avancées

Et ceci s'est avéré être un bon choix, spécialement avec le bump de performance offert par PHP 7. Avec ce choix, nous sommes confiants sur le fait que nous pouvons offrir une expérience utilisateur rapide et bonne, sinon meilleure. Plus important encore, nous pensons que nous pouvons avoir un moyen plus efficace pour les développeurs de comprendre et de développer sur la plate-forme et de construire des fonctionnalités stables et solides plus rapidement. Cela devrait être rentable même dans le cycle de développement initial, car nous atteignons plus rapidement les étapes bêta et stables avec cette approche. À partir de là, nous serons en mesure d'itérer plus rapidement sur les composants riches, maintenant qu'ils sont purs React.js et non abstraits dans les composants Web.

Cela pourrait sembler être un changement important à ce stade. Ce n'est cependant pas une révolution, c'est plutôt un remaniement interne. La plupart des composants U.I. qui ont été développés en U.I hybride précédemment (basés sur Pjax) peuvent être facilement adaptés sans les recoder et ont été réutilisés. Donc, si vous avez commencé à explorer l'extension de la plate-forme U.I hybride alpha avec Symfony, votre développement devrait également s'adapter très facilement à cette nouvelle approche. Et bien sûr, sous la « peau » de l'interface, tout est resté inchangé, et quand il s'agit de design U.I. et U.X., les choses restent largement inchangées, outre le fait que les directives U.I devront fournir des extraits HTML et CSS frontaux qui cadreront avec cette nouvelle approche - nous avons déjà commencé à travailler là-dessus.

À ce stade, nous travaillons à la sortie d'une version bêta d'eZ Platform Version 2 basée sur cette mise à jour de l'architecture U.I d'ici fin octobre et en ciblant toujours une version stable d'ici la fin de l'année avec un seul composant intégrant toujours du code YUI, l'éditeur de landing page de Studio. Jusqu'à présent, nous avons travaillé dans des repository personnels en phase de développement, mais nous nettoyons et réorganisons le code dans les repository publics finaux sous l'organisation eZ Systems Github (https://github.com/ezsystems/ezplatform-admin-ui pour l'application principale et https://github.com/ezsystems/ezplatform-admin-ui-modules pour les widgets développés avec React.js).

Nous espérons que vous aimerez ce changement, nous pensons que les développeurs Symfony devraient le trouver beaucoup plus accueillant, leur simplifiant la vie et les aidant à faire avancer les choses plus rapidement. Ce qui, après tout, était la demande originale des partenaires et de la communauté. À l'avenir, nous continuerons à simplifier l'architecture, faisant de Symfony la seule dépendance essentielle qu'un développeur devrait connaître pour développer rapidement avec eZ Platform. Les développeurs JS seront toujours les bienvenus, étendant la plate-forme U.I. ou le front-end de leurs sites avec des capacités hautement interactives, sans que ce soit une exigence de base.

N'hésitez pas à laisser vos commentaires ci-dessous.