Zend FR

Hello,

J'avais un peu de peur de ce genre de réaction quand Matthew a annoncé le milestone 1.

La première réponse est non (excepté ce milestone), ZF2 n'est pas une version 5.3 de ZF1. L'annonce ne le précise pas assez, elle aborde juste le cas de Zend\Session qui est le seul composant déjà revu. Tout le MVC entre autres va être revu. Regardes http://framework.zend.com/wiki/display/ … Milestones pour plus de détails. Cette page ne mentionne pas le composant Zend\Db (http://framework.zend.com/wiki/display/ … quirements) ou Zend\Pdf (http://framework.zend.com/wiki/display/ … quirements).

Certains composants ne seront quasiment pas touché (j'ai Zend\Barcode par ex. en tête), d'autres sont déjà fait ou presque (Zend\Cache => http://github.com/marc-mabe/zf2/tree/cache) et d'autres en cours (j'ai par ex. Zend\Service\Flickr => http://github.com/mikaelkael/zf2/tree/zsflickr).

Donc non, ZF2 n'est pas ZF1 en 5.3

@+

PS : je n'énumère pas tout ici, si tu as un composant en tête, n'hésites pas à demander plus d'infos plus précise

Bonsoir,

En fait, je n'attend pas de changements majeurs sur des composants spécifiques. Ce que je trouverais intéressant c'est surtout de repenser un peu le fond du framework pour ajouter de la simplicité et une meilleure cohésion d'ensemble pour que ça colle plus à la réalité. Il existe beaucoup de composants Zend, qui sont  développés et maintenus par leurs contributeurs sans forcément de cohésions entre eux. On peut aussi dire que c'est la force de Zend, mais je pense que l'un n'empêche pas l'autre.

Je souhaitais voir arriver un framework qui enrobe vraiment le modèle objet mis en place par les développeurs et qui simplifie les processus les plus courants dans une application web (multilangue, formulaires, sécurité, etc etc.).

Que le coeur du framework soit plus que le MVC mais un ensemble cohérent et robuste pour gérer un processus de bout en bout. Donc, que certains composants comme Zend_Form, Zend_Validate, Zend_Translate fassent partie du coeur et soient intégrés avec une bonne cohésion d'ensemble. Il faudrait par ex. des mécanismes simples pour gérer le i18n de bout en bout. Aujourd'hui pour mettre en place ce genre de comportement les développeurs doivent eux mêmes bidouiller et batailler sur chaque composant séparément pour réussir à les faire fonctionner ensemble.

Par exemple, simplifier la gestion des formulaires, simplifier et renforcer les processus de validation, parce qu'aujourd'hui on tombe sans arrêt sur des cas particuliers que le framework ne sait pas gérer, ou alors il faut jongler avec des sub-forms ou autre, pour des développeurs non experts c'est une énorme perte de temps.

Ce serait intéressant de réorienter le coeur du framework autour du modèle métier, en permettant par exemple de mapper directement des formulaires sur des objets, en gérant les imbrications, de valider directement des objets métiers, de placer l'injection de dépendances au coeur du framework pour simplifier la scalabilité et les tests. Plein de questions récurrentes dans les applications web qui peuvent trouver une réponse grâce à un framework robuste.

J'imaginais un core pour le framework, et un éco-système de composants autour. Beaucoup de composants sont extrêmement utiles et intéressants, et utilisés ensemble ils formeraient un tronc commun solide. Aujourd'hui c'est aux développeurs de faire ce qu'ils peuvent pour les utiliser ensemble. On se retrouve avec un framework par dessus un framework, et donc finalement un framework maison (ce qu'il faut éviter) parce que le ZF ne permet pas nativement de répondre à une problématique d'ensemble.

Je vais pas trop pousser pour pas m'éparpiller, j'ai une idée très précise de ce que j'espérais voir arriver, et j'ai peur que nous soyons encore loin et que My_Framework extends Zend_Framework soit inévitable.

Evidemment je sais que le travail des contributeur est énorme et on ne peut que les remercier pour ce qu'ils font. Mon but ici n'est pas de jeter la pierre hein, je m'inquiète c'est tout


A+ benjamin.

Je prends cette m1 uniquement comme une base de travail commune pour commencer le développement de ZF 2. C'est donc à mon sens une release purement pour les contributeurs, et donner des nouvelles. ZF 2 n'est pas une version namespace PHP 5.3 de ZF1, mais un projet en PHP 5.3, et non un portage de PHP 5.2 à 5.3 je pense. Après un sondage sur camelcase contre acronym, un sondage vient d'être lancé à propos de l'underscore en préfix d'attributs, et méthodes. Il y a le cas des classes Services, et faire le tour de l'ensemble des composants. Je ne vois pas de sortie publique avant un ou deux ans pour ZF 2 : il y a tellement de choses que tout le monde souhaite ^^

Je vois un peu l'idée que tu attendais de ZF 2. Je ne suis pas sûr que ça soit le but de ZF 2 pour plusieurs raisons. Déjà, c'est du haut vol pour moi, donc tu fais une sélection draconienne au niveau contributeurs pour savoir mettre cela en place. Il faut déjà arriver à utiliser le concept proprement.
Après je pense qu'il faut que le noyau dur de ZF mette en place certains nouveaux concepts comme la volonté de plugin & co. Le MVC englobe une bonne partie de ZF est ne peut pas partir dans tous les sens. Il n'y a aucune mention de Zend_Tool, mais cela pourrait être revu pour automatiser des étapes récurrentes.
Ils souhaitent aussi régler les problèmes de performance dans ZF2.

Au final, je ne suis pas sûr que le tout automatique soit leur objectif. Il suffit de comparer l'orientation de Symfony et Zend Framework par exemple. Je suis assez de ton avis qu'au final, nous avons besoin de pouvoir développer un site au plus vite en ayant un fauteuil tout prêt pour gérer tous les aspects récurrents propre à un site web indépendant du métier propre. En rajoutant, un support de debug (comme zfdebug, ou un errorcontroller avancé pour savoir remonter la requête ou la variable à problème), avoir un checkeur de config, et prérequis. L'idéal serait d'avoir à définir le métier dont on a besoin, et la partie HTML/CSS/image. Cela me fait penser au fait que Symfony est un générateur de backoffice.

Libre à toi de lancer le débat sur la mailing list des contributeurs

Je pense que l'explication c'est que tout le monde n'est pas architecte logiciel, ou concepteur.

PS : à propos des frameworks maisons, j'en connais qui ne partagent pas ton avis lol (Sekajin, la personne qui tient phppro, etc)

Ce que j'aime justement dans ce framework, c'est qu'on peut en faire n'importe quoi en l'étendant afin qu'il colle parfaitement au besoin unique de telle entreprise ou de tel projet.
C'est d'ailleurs le rôle de l'architecte logiciel sur un projet

Pour la partie modèle, entity il me semblait que ZF annonçait une intégration simplifiée de Doctrine 2. J'aurai raté un épisode?

Hello,

@philippe :

Oui j'ai lu le wiki en long en large et en travers (et j'espionne le chan IRC des contributeurs)
J'ai d'ailleurs posé des questions sur Nabble et j'ai eu quelques éléments de réponse (de Matthew).

J'ai mis quelques remarques sur le wiki aussi, notamment pour Zend_Form 2.0 qui a mon avis sera un élément clé (sans parler de la partie html que je n'utilise de toute façon pas). J'espère vraiment qu'ils vont l'articuler pour fonctionner étroitement avec le modèle métier de l'application.


A+ benjamin.

Je parle surtout des entités. Le mot "étroitement" est peut être mal choisi

Comme je l'explique dans mon exemple sur le wiki, pour simplifier la plupart des cas d'utilisations il faudrait pouvoir (de manière facultative) faire fonctionner les objets métiers et Zend_Form ensemble. Après l'objet peut être ce que tu veux, du moment qu'il respecte des règles simples comme des getters/setters bien formatés par ex.

Je reprend l'exemple du wiki :

class Foo 
{ 
    protected $bar; 
    protected $baz; 
 
    public function getBar() 
    { 
        return $this->bar; 
    } 
       
    public function setBar($bar) 
    { 
        $this->bar = $bar; 
        return $this; 
    } 
 
    public function getBaz() 
    { 
        return $this->baz; 
    } 
       
    public function setBaz($baz) 
    { 
        $this->baz = $baz; 
        return $this; 
    } 
}

$foo = new Foo(); 
$form = new FooForm(array(), $foo); 
// filters, sets form data and populate object if it exists. 
$form->setData(array('bar' => 'some value', 'baz' => 'other value')); // or $_POST or other 
 
$foo = new Foo(); 
$foo->setBar('some value'); 
 
$form = new FooForm(array(), $foo); 
$form->getElement('bar')->getValue(); 
// some value

Comme les validateurs vont être vraiment détachés, il sera facile de créer des validateurs "métier" dans une autre couche de l'application. Le controller lui, s'occuperait simplement de "binder" les données sur le formulaire, le formulaire filtre les données et peuple (entièrement ou en parti) un objet. C'est ensuite l'objet qui passe dans les couches suivantes et non pas le formulaire.

Ce type de fonctionnalité ferait gagner un temps considérable de dév. et réduirait aussi pas mal le nombre de lignes code.

Le gros avantage de Doctrine 2 là dedans, c'est qu'on ne soucie pas un seul instant de la persistance puisque les entités sont de véritables objets PHP dont les classes n'étendent plus de classe doctrine. On y arrive, doucement, mais on commence à avoir des outils qui permettent vraiment de bien détacher nos objets métier et ça serait bien de continuer dans cette voie en facilitant les process comme les gestions de formulaires qui restent aujourd'hui un peu fastidieuses.

Aujourd'hui, c'est le genre de possibilité qui seront déterminantes pour moi dans le choix d'un framework PHP pour nos prochains projets. Au moins on retourne à l'origine du problème et les développeurs se concentreront sur le modèle métier (le coeur de l'application), plutôt que sur la compréhension du framework


A+ benjamin.

Dernière modification par Delprog (24-08-2010 10:37:06)