Zend FR

Consultez la FAQ sur le ZF avant de poster une question

Vous n'êtes pas identifié.

#1 19-12-2012 22:09:13

imsouf
Membre
Date d'inscription: 19-12-2012
Messages: 12

Votre avis sur le squelette ZF2

Bonjour,

étant habitué à utiliser mon propre "framework" j'ai voulu passer le cap et passer à quelque chose de plus standard.

Depuis quelques jours je découvre Zend 2 (je n'ai jamais touché au premier) et les surprises sont chaque jour un peu plus décevantes. La première étant que la documentation est particulièrement incomplète, la seconde que le squelette officiel est non seulement lourd à appréhender mais aussi à utiliser.

Ceci étant mon avis et j'aimerais connaître le votre à ce sujet pour avoir un peu plus de recul.

D'autre part étant largement déçus par le skelette officiel j'ai voulu réadapter mon framework personnel en utilisant la couche MVC de Zend 2 (Routeur, Controllers et Views).
Et là gros hic, aucune documentation réelle (la plupars de mes réponses, je suis obligé d'aller les chercher dans les sources de la librairie directement, voir même dans les testes unitaires du framework...). Bref au final je sens que l'idée n'est pas hyper viable, je tire à peine partie de Zend et que pour le coup de vouloir faire les choses de manière un peu plus standard, c'est plutôt perdu.

N'y a t-il pas un squelette alternatif un peu plus light que l'officiel ?

Au final je suis assez déçus, durants des mois et des années, Zend était dans mon idée un peu comme un "graal" ou plutôt comme la crème en terme de framework. Mais je me rends compte qu'a part une communauté (qui semblerait absente sur la version 2 pour l'instant) et une librairie un peu plus fournie, Zend ne m'offre pas grand chose de plus, en tout cas en terme de structure de projet, que ce que j'ai pu faire jusqu'à aujourd'hui.  Alors peut-être que j'ai pris la chose du mauvais côté et que je n'ai pas encore réussi a voir le bon côté ?

En vous remerciant.

Dernière modification par imsouf (19-12-2012 22:17:06)

Hors ligne

 

#2 19-12-2012 22:51:13

Bouks
Membre
Lieu: Paris
Date d'inscription: 31-08-2012
Messages: 241

Re: Votre avis sur le squelette ZF2

imsouf a écrit:

...
le squelette officiel est non seulement lourd à appréhender mais aussi à utiliser.
Ceci étant mon avis et j'aimerais connaître le votre à ce sujet pour avoir un peu plus de recul.
...

Mon avis est que tu exagères un tout petit peu énormément.

imsouf a écrit:

N'y a t-il pas un squelette alternatif un peu plus light que l'officiel ?

Personnellement, la seule modif que je fait dans le skeleton c'est de supprimer le dossier src des modules pour avoir directement le dossier Controller.

Tu as d'autres idées qui pourrait nous intéresser ?

imsouf a écrit:

Au final je suis assez déçus, durants des mois et des années, Zend était dans mon idée un peu comme un "graal" ou plutôt comme la crème en terme de framework.

Durant des mois et des années les écoles d'ingénieurs étaient dans mon idée comme la crème de la crème ...

imsouf a écrit:

Mais je me rends compte qu'a part une communauté (qui semblerait absente sur la version 2 pour l'instant)

Effectivement pour ma part je serai absent du 24 décembre au 3 janvier. Faudrait que tu vois avec les autres s'il y a une permanence pendant les fêtes.


22914720

Hors ligne

 

#3 19-12-2012 23:21:20

imsouf
Membre
Date d'inscription: 19-12-2012
Messages: 12

Re: Votre avis sur le squelette ZF2

A priori ce n'est pas le bon endroit pour avoir une réponse constructive qui pourrait me faire changer d'avis. Bien que j'apprécie ton humour.

Hors ligne

 

#4 20-12-2012 00:20:51

bakura
Administrateur
Date d'inscription: 30-01-2010
Messages: 353

Re: Votre avis sur le squelette ZF2

Salut,

Ne t'en fais pas pour Bouks, c'est notre bout-en-train local ;-).

Je le rejoins cependant concernant le squelette officiel. Qu'as-tu à lui reprocher exactement ? Il n'est pas spécialement lourd ni difficile à appréhender, et pour le coup il montre de bonnes pratiques d'organisation de code et n'a normalement pas à être modifié tant que ça.

De manière générale, la difficulté vient surtout de plusieurs éléments : les configurations via des tableaux PHP qui peuvent effectivement sembler compliquées (Symfony 2 utilisent beaucoup d'annotations ce qui réduit le code, tandis que ZF 2 utilise surtout des tableaux PHP tout simple... chaque approche a ses avantages et ses inconvénients).

L'autre difficulté est de comprendre comment fonctionne l'injection de dépendances, et notamment le service manager. Mais une fois ceci bien compris, c'est très simple et, pour le coup, le framework est relativement homogène (chaque composant utilise la même logique de plugin manager...).

Code:

Et là gros hic, aucune documentation réelle (la plupars de mes réponses, je suis obligé d'aller les chercher dans les sources de la librairie directement, voir même dans les testes unitaires du framework...). Bref au final je sens que l'idée n'est pas hyper viable, je tire à peine partie de Zend et que pour le coup de vouloir faire les choses de manière un peu plus standard, c'est plutôt perdu.

Je suis d'accord avec toi sur ce point, la documentation est incomplète et c'est d'ailleurs souvent le gros point faible de bien des projets open-source. Je suis moi même contributeur de ZF 2 et "mainteneur officiel" du composant sur les formulaires, la grande majorité des contributeurs travaillent sur ZF 2 pendant leur temps libre et effectivement, écrire la documentation est long et fastidieux, mais on tente de faire de notre mieux. On a pensé un temps à obliger chaque contributeur d'écrire la documentation sur ce à quoi ils contribuent, mais les gens ne contribueront tout simplement plus.

Après, tu as quand même des ressources bien faite. Le quick start de la documentation officielle est plutôt bien foutue, et surtout, n'hésite pas à rechercher sur les blogs (tu as une liste de blogs qui traitent souvent de ZF 2 : http://framework.zend.com/participate/blogs/). C'est souvent la meilleure source d'exemples (et comme tu l'as dit toi même, lire les tests unitaires permet également d'appréhender certains composants. Tu peux regarder aussi ce lien : http://php-underground.blogspot.fr/2012 … ork-2.html

Code:

N'y a t-il pas un squelette alternatif un peu plus light que l'officiel ?

Le squelette officiel est relativement light. Tu peux éventuellement supprimer quelques trucs comme le dossier "languages", l'initialisation du translator... si tu ne te sers pas de ces fonctionnalités.

Code:

Au final je suis assez déçus, durants des mois et des années, Zend était dans mon idée un peu comme un "graal" ou plutôt comme la crème en terme de framework. Mais je me rends compte qu'a part une communauté (qui semblerait absente sur la version 2 pour l'instant) et une librairie un peu plus fournie, Zend ne m'offre pas grand chose de plus, en tout cas en terme de structure de projet, que ce que j'ai pu faire jusqu'à aujourd'hui.  Alors peut-être que j'ai pris la chose du mauvais côté et que je n'ai pas encore réussi a voir le bon côté ?

Encore une fois, il faut que tu me dises ce que tu attends exactement. ZF 2 est un excellent framework moderne, qui repose sur des concepts qui sont effectivement pas forcément facile d'accès de prime abord, mais ça vaut le coup.

Après je prêche pour ma paroisse évidemment, mais tu peux tester Symfony 2 qui est aussi un excellent framework. Il y a en a d'autres : Aura, Phalcon, Yii... Si Zend Framework 2 ne te convient pas tu peux en changer !

Le seul point valide sur ton discours c'est la documentation... Après on a beaucoup de gens qui se plaignent du manque de documentation, mais qui ne contribuent pas pour autant dès qu'ils comprennent les concepts, donc c'est toujours un peu dommage. Contribuer c'est facile, et si tu estimes qu'il y a certains manques, et que tu as réussi à comprendre certains concepts par toi même, n'hésite pas à compléter la documentation, on se fera un plaisir de l'ajouter ;-).

Si tu as des questions, n'hésite pas !

Hors ligne

 

#5 20-12-2012 01:25:05

imsouf
Membre
Date d'inscription: 19-12-2012
Messages: 12

Re: Votre avis sur le squelette ZF2

Oui comme tu le dis le principal problème vient sûrement de la documentation car le quickstart (avec la création d'un album) traite la chose assez superficiellement. Avec le peu de documentation actuellement présente il est difficile d'aller plus loin. Par exemple il n'y a aucun point sur la manière dont Zend traite les sessions. Et ça me bloque pour me lancer dans un projet avec Zend.


D'autre part j'aime bien savoir ce que fait mon application quand je la lance, pendant qu'elle tourne et quand elle s'arrête. Par exemple a chaque chargement de page on a par exemple ce scénario :

Une requête est faite vers mon server :
je démarre la session
je lis si le client avait telle information stockée en session
     si oui je le redirige (par exemple)
je lis si le client avait telle information stockée en cookies
     si oui je supprimer tel cookie (par exemple)
je lis si le client vient de telle page
     si oui je le log dans ma base de donnée

je lance  mon controller,ma view,...,

et eventuellement d'autres actions apres le chargement de mon controller...


Pour l'exprimer différemment ce serait une sorte d'evenement onScriptBegin(){/**/});     onScriptEnds(){/**/};


Pour le squelette officiel je lui reproche d'avoir une architecture de modules trop vaste. On s'y perd et on n'a l'impression de ne pas maîtriser son application.
En bref l'idée de ne pas avoir le contrôle de mon application me dérange énormément et c'est l'impression que me donne le squelette officiel de part son architecture de modules trop vaste et de ce que je viens d'exprimer à propos du scénario de l'application.

Je reformule mon ressenti une troisième fois pour bien comprendre :
Quand un client demande une page sur mon serveur, il est pour moi important de savoir ce que fait le script (il faut toujours être maître de son application) et être maître de son application passe (selon moi) également par une architecture de fichiers plus simple que celle du squelette Zend 2 qui est relativement dense. Je me perds dans tous les sous dossiers, tous les fichiers de configurations un peu partout...


Après comme tu le dis l'injection de dépendances est difficile à utiliser car ça donne une étape supplémentaire assez lourde (je prends l'exemple du tablegateway dans le quickstart qu'il faut configurer par un array en deux fois et qui n'est pas très explicite. Doit-on le faire à chaque fois que l'on crée un nouveau Model ?)


Je vois également mal comment gérer plusieurs site sur un même dossier Module sans s'y perdre. Je dois mélanger les modules de mon backoffice et de mon frontOffice dans un seul et même dossier module sans avoir d'unicité entre les modeles ? Car à côté de Module, Public, Data, je trouve mieux d'avoir un dossier de controlleurs-views par site (back, front, éventuellement un deuxieme front qui utilise les même modeles) puis des modeles dans un dossier à part pour pouvoir garder une unicité dans notre librairie interne et juste avoir besoin de changer la navigations et l'affichage via des routeurs/controleur/view distincts.


Sinon pour te répondre au niveau des autres framework : symfony je deteste son système de template, Yii je le trouve beaucoup trop intrusif, (les 2 autres je ne les connais pas), codeIgniter : 0 rigueur dans le code...



PS : Pour chipoter un peu parceque j'ai trouvé ça et que ça me dérange un ptit peu quand même :
Zend me séduit vraiment dans ses classes (surtout sont la class Form qui est en tout points similaires à celle que j'avais faite moi même mais en plus mature) et par son omniprésence dans les entreprises mais j'ai quand même remarqué des faiblesse. Par exemple en essayant d'utiliser la class de router je suis tombé sur un os pour la méthode match. J'ai donc regardé dans la library ce que fesait la méthode match du TreeRouteStack :

public function match(Request $request)
    {
        if (!method_exists($request, 'getUri')) {
            return null;
        }

/* ...*/
}
$request étant une implémentation de requestInterface.  RequestInterface étant une interface vide
match regarde si $request passée en paramétre possède la method getUri. Je ne trouve pas ça très clean... Il aurait fallu que get Uri soit dans l'interface RequestInterface..
Au final j'ai mis longtemps avant de tomber sur le PhpEnvironement\Request...
Bref c'était surtout pour chipoter. smile

Dernière modification par imsouf (20-12-2012 01:44:49)

Hors ligne

 

#6 20-12-2012 09:33:40

Orkin
Administrateur
Lieu: Paris
Date d'inscription: 09-12-2011
Messages: 1261

Re: Votre avis sur le squelette ZF2

Salut Imsouf, concernant l'intervention de Bouks il faut aussi tenir compte des évènements actuels. Nous sommes en période de fêtes de fin d'années (si on survie à la fin du monde) donc on est tous très pris par nos occupations IRL, la bonne humeur est de la partie donc un poil d'humour dans ces moments c'est toujours appréciable. On est tous ici sur notre temps libre et notre bon vouloir et je t'avoue que personnellement en ces moments de fête le forum est un peu vide et ça se comprend !

imsouf a écrit:

Oui comme tu le dis le principal problème vient sûrement de la documentation car le quickstart (avec la création d'un album) traite la chose assez superficiellement. Avec le peu de documentation actuellement présente il est difficile d'aller plus loin. Par exemple il n'y a aucun point sur la manière dont Zend traite les sessions. Et ça me bloque pour me lancer dans un projet avec Zend.

Alors là dessus je trouve pourtant que la documentation du quickstart est pas trop mal foutue après je n'aime pas ce qui y est abordé mais elle a le mérite d'expliquer comment commencer pour les débutants, il ne faut pas se tromper de publique. C'est un tutoriel pour novice (git, composer, php, apache, zf) donc il aborde pas les points complexe que tu souhaiterais avoir.

Pour ça tu as les webinars qui approfondissent un peu plus et si tu veux aller encore plus loin, tu peux venir parler chiffon directement sur IRC. Tous les contributeurs sont abordables et sympathiques (sauf Bakura mais c'est un jeune petit con alors on le pardonnera ^^) donc n'hésites pas ! Je te recommande aussi d'utiliser doctrine ça apporte un peu plus de simplicité l'ORM et son implémentation dans le ZF2 sont vraiment très bien foutu.

imsouf a écrit:

Pour le squelette officiel je lui reproche d'avoir une architecture de modules trop vaste. On s'y perd et on n'a l'impression de ne pas maîtriser son application.
En bref l'idée de ne pas avoir le contrôle de mon application me dérange énormément et c'est l'impression que me donne le squelette officiel de part son architecture de modules trop vaste et de ce que je viens d'exprimer à propos du scénario de l'application.

Tu as plusieurs outils pour ça le premier qui me vient en tête c'est ZDT (Zend Developper Tool) il te permet de rajouter une barre en haut ou en bas de ton site avec différentes informations : les requêtes effectuées, la route sur laquelle tu te trouves etc ...
L'architecture du squelette n'est vraiment pas compliquée à mettre en place et si tu y passes un peu de temps tu verras qu'elle est même très logique (bon il y a toujours des choses à améliorer c'est certain) mais disons qu'à l'utilisation tu t’aperçois que pour que ça fonctionne sans te prendre la tête il n'y a rien à faire (par exemple l'ajout de vue pour les contrôleurs mais aussi de template pour les aides de vue). Certes ça fait un ensemble de fichiers assez important pour commencer mais au final tu as la configuration globale de ton application dans le dossier config, les fichiers statiques dans public et le reste dans module avec la possibilité d'avoir une configuration spécifique pour chaque module.

imsouf a écrit:

Je reformule mon ressenti une troisième fois pour bien comprendre :
Quand un client demande une page sur mon serveur, il est pour moi important de savoir ce que fait le script (il faut toujours être maître de son application) et être maître de son application passe (selon moi) également par une architecture de fichiers plus simple que celle du squelette Zend 2 qui est relativement dense. Je me perds dans tous les sous dossiers, tous les fichiers de configurations un peu partout...

Je pense que ça vient tout simplement d'un manque de connaissance du framework ça viendra avec le temps (ça reprend un peu ce que j'ai dit plus haut).

imsouf a écrit:

Après comme tu le dis l'injection de dépendances est difficile à utiliser car ça donne une étape supplémentaire assez lourde (je prends l'exemple du tablegateway dans le quickstart qu'il faut configurer par un array en deux fois et qui n'est pas très explicite. Doit-on le faire à chaque fois que l'on crée un nouveau Model ?)

Tablegateway j'aime pas je te conseil vivement doctrine big_smile. Pour l'injection de dépendances et le service manager c'est vraiment des outils super. C'est pas simple à aborder au début mais quand tu as compris c'est tout simplement génial !!

imsouf a écrit:

Je vois également mal comment gérer plusieurs site sur un même dossier Module sans s'y perdre. Je dois mélanger les modules de mon backoffice et de mon frontOffice dans un seul et même dossier module sans avoir d'unicité entre les modeles ? Car à côté de Module, Public, Data, je trouve mieux d'avoir un dossier de controlleurs-views par site (back, front, éventuellement un deuxieme front qui utilise les même modeles) puis des modeles dans un dossier à part pour pouvoir garder une unicité dans notre librairie interne et juste avoir besoin de changer la navigations et l'affichage via des routeurs/controleur/view distincts.

Alors là je ne te comprend pas. Pour moi tu as un site par squelette et rien de plus. Concernant la séparation du code entre BO et FO Bakura en avait parlé dans un sujet de ce forum, c'est pas forcément l'idéal de les séparer. Pourquoi ? Car un module c'est quoi ? C'est une séparation du code qui apporte de nouvelles fonctionnalités à ton application. Par exemple la messagerie privée. Normalement un module doit pouvoir être autonome c'est à dire que lorsqu'il est ajouté à une application (qui respecte un minimum de convention, si le module messagerie privée a besoin d'une table user et qu'il n'y en a pas c'est sûr que ça ne pourra pas fonctionner) il doit pouvoir s'intégrer directement. Ca c'est la théorie dans la pratique il va atteindre un tel niveau d'abstraction qu'au final tu perds plus de temps à faire ton module que ce qu'il t'en fait gagner. On peut donc dire qu'un module permet en pratique de simplement séparer des parties de ton application qui sont des fonctionnalités bien distinctes. Pour un site de vente en ligne par exemple tu pourrais avoir ce genre de modules : catalogue, panier, achat, blog (pour parler des articles), messagerie privée. Forcément le module achat peut difficilement fonctionner sans le catalogue ni le panier donc il y a des dépendances mais ils peuvent fonctionner sans blog ou messagerie privée.
Tout ça pour en venir à la conclusion que la partie FO ou BO d'un module n'est pas une nouvelle fonctionnalité de ton application mais une fonctionnalité de ton module, tu vas donc intégrer la partie BO de l'achat dans le module Achat (qui peut être accessible via des routes différentes ça c'est de la configuration, tu peux y rajouter des ACLs pour le protéger correctement etc ...). Dans un premier temps j'aurais pensé à faire comme toi "2 applications séparées" mais ça n'a pas de sens dans ce cas là ton BO n'est pas autonome il a besoin du FO et de ses modèles !

imsouf a écrit:

$request étant une implémentation de requestInterface.  RequestInterface étant une interface vide
match regarde si $request passée en paramétre possède la method getUri. Je ne trouve pas ça très clean... Il aurait fallu que get Uri soit dans l'interface RequestInterface..
Au final j'ai mis longtemps avant de tomber sur le PhpEnvironement\Request...
Bref c'était surtout pour chipoter. smile

Il peut rester des coquilles par-ci par là. Je maitrise pas assez pour connaitre le but définitif mais admettons que tu souhaites faire ta propre classe request l'interface te permet simplement que le code du ZF fonctionne rien ne t'oblige après dans ta classe de mettre la méthode car il y a peut être un fonctionnement différent si cette méthode est présente ou non. Si ce n'est pas le cas c'est débile effectivement smile

Hors ligne

 

#7 20-12-2012 11:20:19

imsouf
Membre
Date d'inscription: 19-12-2012
Messages: 12

Re: Votre avis sur le squelette ZF2

Bonjour Orkin,
Oui je comprends pour noël, c'est pareil par ici :p


Je jetterai un coup d'oeil aux webinars.

Pour l'IRC pourquoi pas, c'est toujours mieux pour partager nos connaissances et expériences d'utilisation. Aurais-tu les informations de connexion s'il te plaît ?


De même pour ZDT je m'y pencherais, par contre je me questionne toujours sur comment faire pour executer un script à chaque chargement d'une page ? Par exemple à chaque fois qu'un client demande une page on l'ajoute à sa route de navigation pour pouvoir la retracer après (ce n'est qu'un exemple parmi d'autres)


Pour Doctrine je ne suis pas fan des ORM sur de gros projets. A la vue des ressources que pompent un ORM (de ce que j'ai pu lire sur le web) j'ai du mal à prendre le risque pour une entreprise d'utiliser ce genre d'outil pour se rendre qu'au final ça plombe toutes les perf du site et de devoir repasser du temps de dev pour revenir en arrière.




Pourquoi je souhaite séparer BO et FO ? Parceque les controllers et les views de chacuns sont selon moi différents. Par contre les modèles restent les mêmes. Un client, reste un client avec un nom, prenom, email.... par contre on ne les traite pas de la même manière. Sur le FO par exemple on ne pourra pas changer l'email, alors que sur le BO on poura (ce n'est qu'un exemple). Dans tous les cas le modèles est capable de modifier l'emails, mais seulement les controllers du BO en donneront la possibilité, et seulement les views du BO en afficheront la possibilité (peut-être que ma conception du MVC est erronée par rapport aux normes ? Mais je trouve ça plus simple est plus modulable).

Apres pourquoi utiliser le même squelette pour deux sites ? Je travail sur un gros projet qui se voue à faire du multi site. Mais du multi site assez similaires. Globalement, encore une fois juste les views et les controllers changeront. Les modèles resteront les mêmes d'un site à l'autre. Et si je modifie le modèle d'un site car il y avait une erreur, il faudra alors modifier le modele du second (d'autant plus que la base de donnée est commune) donc ça fait du travail en doublon à chaque fois !! Il me faut alors une librairie commune pour gérer ça, donc je me vois mal utiliser deux squelettes.
Deuxième possibilité : je fais mes modules à l'extérieur du squelette pour que peut importe le squelette je puisse aller les chercher. Mais là encore, je n'utilise plus vraiment le squelette officiel.
Après je peux utiliser la deuxième possibilité tout en utilisant les modele dans les modules de zend qui hériteraient de ceux en dehors du squelette. Mais là alors quand je rajoute un modele, il faut que je le fasse dans chaque squelette... !

Hors ligne

 

#8 20-12-2012 11:32:15

Orkin
Administrateur
Lieu: Paris
Date d'inscription: 09-12-2011
Messages: 1261

Re: Votre avis sur le squelette ZF2

imsouf a écrit:

Pour l'IRC pourquoi pas, c'est toujours mieux pour partager nos connaissances et expériences d'utilisation. Aurais-tu les informations de connexion s'il te plaît ?

Ca doit être zftalk.dev et zftalk si je dis pas de conneries j'y suis pas souvent. Tu devrais trouver les informations sur le site du zf. C'est sur les serveur freenode

imsouf a écrit:

De même pour ZDT je m'y pencherais, par contre je me questionne toujours sur comment faire pour executer un script à chaque chargement d'une page ? Par exemple à chaque fois qu'un client demande une page on l'ajoute à sa route de navigation pour pouvoir la retracer après (ce n'est qu'un exemple parmi d'autres)

Tu peux le faire en ajoutant un évènement sur le disptach dans ton Module.php

imsouf a écrit:

Pour Doctrine je ne suis pas fan des ORM sur de gros projets. A la vue des ressources que pompent un ORM (de ce que j'ai pu lire sur le web) j'ai du mal à prendre le risque pour une entreprise d'utiliser ce genre d'outil pour se rendre qu'au final ça plombe toutes les perf du site et de devoir repasser du temps de dev pour revenir en arrière.

C'est possible j'ai pas trop cherché d'infos. Après si la coche service est bien faite la migration est assez rapide à faire.

imsouf a écrit:

Pourquoi je souhaite séparer BO et FO ? Parceque les controllers et les views de chacuns sont selon moi différents. Par contre les modèles restent les mêmes. Un client, reste un client avec un nom, prenom, email.... par contre on ne les traite pas de la même manière. Sur le FO par exemple on ne pourra pas changer l'email, alors que sur le BO on poura (ce n'est qu'un exemple). Dans tous les cas le modèles est capable de modifier l'emails, mais seulement les controllers du BO en donneront la possibilité, et seulement les views du BO en afficheront la possibilité (peut-être que ma conception du MVC est erronée par rapport aux normes ? Mais je trouve ça plus simple est plus modulable).

Tu peux très bien avoir des vues différentes au sein d'un même contrôleur. On peux imaginer des actions boXXXXAction dans ces contrôleurs avec les vues adéquat.

imsouf a écrit:

Apres pourquoi utiliser le même squelette pour deux sites ? Je travail sur un gros projet qui se voue à faire du multi site. Mais du multi site assez similaires. Globalement, encore une fois juste les views et les controllers changeront. Les modèles resteront les mêmes d'un site à l'autre. Et si je modifie le modèle d'un site car il y avait une erreur, il faudra alors modifier le modele du second (d'autant plus que la base de donnée est commune) donc ça fait du travail en doublon à chaque fois !! Il me faut alors une librairie commune pour gérer ça, donc je me vois mal utiliser deux squelettes.
Deuxième possibilité : je fais mes modules à l'extérieur du squelette pour que peut importe le squelette je puisse aller les chercher. Mais là encore, je n'utilise plus vraiment le squelette officiel.
Après je peux utiliser la deuxième possibilité tout en utilisant les modele dans les modules de zend qui hériteraient de ceux en dehors du squelette. Mais là alors quand je rajoute un modele, il faut que je le fasse dans chaque squelette... !

Dans ce cas pourquoi ne pas faire simplement une API commune sous forme de webservice (SOAP ou REST) ? Comme ça ces deux applications interrogent la même chose est c'est bien dispatché des deux côtés. Si la partie applicative de ces applications est commune ça devrait fonctionner sans soucis.

Hors ligne

 

#9 20-12-2012 12:49:17

imsouf
Membre
Date d'inscription: 19-12-2012
Messages: 12

Re: Votre avis sur le squelette ZF2

Bien vu Orkin pour le web service. Est-ce que Zend offre un support particulier pour faciliter l'utilisation d'un webs service ? (tant qu'à faire autant en profiter !)

Tu peux le faire en ajoutant un évènement sur le disptach dans ton Module.php

Comment marche le dispatch dont tu parle. As-tu un lien ?

Hors ligne

 

#10 20-12-2012 14:33:06

bakura
Administrateur
Date d'inscription: 30-01-2010
Messages: 353

Re: Votre avis sur le squelette ZF2

Quand un client demande une page sur mon serveur, il est pour moi important de savoir ce que fait le script (il faut toujours être maître de son application) et être maître de son application passe (selon moi) également par une architecture de fichiers plus simple que celle du squelette Zend 2 qui est relativement dense. Je me perds dans tous les sous dossiers, tous les fichiers de configurations un peu partout...

Je suis pas forcément d'accord... C'est effectivement intéressant de savoir comment ça fonctionne, particulièrement si tu as des besoins spécifiques en terme de performance, d'extensibilité, ou juste par curiosité, mais c'est loin d'être indispensable.

Si ça t'intéresse tu as un résumé de ce que le framework fait en interne lorsqu'une requête est reçue : http://zendframework2.de/en/cheat-sheet.html

Pour résumer :

1) Toutes tes requêtes sont envoyées au fichier index.php, qui va lire ta config, charger les différents modules que ton application utilise (config, initialisation...).
2) Une fois les modules chargés, le fichier index.php va créer une application (un objet de type Zend\Mvc\Application), et la lancer.
3) Le routeur va être lancé et, à partir de tes configurations (tes routes), il va récupérer le contrôleur, le module, l'action... vers lesquels envoyer la requête. En même temps, le routeur va lancer plusieurs évènements via le gestionnaire d'évènements (par exemple l'évènement "dispatch.error" si la requête ne correspond à aucune route que tu as définis).
4) Ces différents évènements vont être capturés, puis l'action va être appelée, la vue rendue, et renvoyer au client.

Ce n'est qu'un aperçu très très global, en interne, le framework fait BEAUCOUP plus de choses, c'est pourquoi je pense pas que ça soit primordial de savoir exactement comment fonctionne le framework. Connaît juste les grandes étapes principales, les évènements levés afin de pouvoir greffer ton code... et ça devrait suffire smile.

Pour Doctrine je ne suis pas fan des ORM sur de gros projets. A la vue des ressources que pompent un ORM (de ce que j'ai pu lire sur le web) j'ai du mal à prendre le risque pour une entreprise d'utiliser ce genre d'outil pour se rendre qu'au final ça plombe toutes les perf du site et de devoir repasser du temps de dev pour revenir en arrière.

J'ai lu beaucoup de choses sur les ORM, sur certains forums de développement ou j'ai été presque insulté (et j'abuse à peine) par certains gurus du SQL qui criaient au scandale à l'utilisation d'un ORM et de ses performances.

Au final, maintenant que j'ai une application quasiment en production, je peux t'assurer que la part de l'ORM est négligeable. Mon application est extrêmement rapide alors que j'utilise Doctrine.

De manière générale, Doctrine 2 est un ORM extrêmement rapide (et les dernières versions encore plus), et surtout facilite énormément le développement. Evidemment, l'ORM n'est pas magique. Si tu écris tes requêtes n'importe comment, évidemment que ce sera lent. Mais un ORM bien utilisé (comprendre : bien savoir comment architecturer tes entités, écrire correctement tes requêtes) ne devrait poser aucun problème de performance.

Il faut également penser à un cache APC, à bien connaître les différentes optimisations possibles lorsque tu passes en production (par exemple, Doctrine 2 a différents mécanismes de cache : cache de requête, cache des annotations, cache de la conversion DQL -> SQL...). Une fois toutes ces optimisations mises en place il n'y a plus aucun soucis ;-).

Après je peux utiliser la deuxième possibilité tout en utilisant les modele dans les modules de zend qui hériteraient de ceux en dehors du squelette. Mais là alors quand je rajoute un modele, il faut que je le fasse dans chaque squelette... !

Je ne suis pas sûr de comprendre... Ce squelette n'est qu'une base minimale d'une application.

Bien vu Orkin pour le web service. Est-ce que Zend offre un support particulier pour faciliter l'utilisation d'un webs service ? (tant qu'à faire autant en profiter !)

Tu peux utiliser le contrôleur AbstractRestfulController, qui te permet de faire une API REST.

Hors ligne

 

#11 26-12-2012 16:22:02

imsouf
Membre
Date d'inscription: 19-12-2012
Messages: 12

Re: Votre avis sur le squelette ZF2

Bonjour,

Alors après quelques expériences c'est vrai que le squelette devient très compréhensible. C'est surtout une question de prise en main comme vous le disiez.

J'ai tout de même simplifier la structure de mes modules pour avoir la suivante :

Module
    config
    Controller
    Form
    Model
    Test
    View



Reste toujours le problème de documentation, et justement je ne trouve toujours pas d'informations concernant les évenements disponnibles dans le squelette par défaut.
Par exemple dans le module Application il ya par défaut une méthode onBootstrap.
Je n'arrive pas à mettre la main sur une liste exhaustive de ce type d'évenement.

En avez-vous une ?

En vous remerciant et en vous souhaitant de joyeuses fêtes de fin d'année.

Dernière modification par imsouf (26-12-2012 16:27:46)

Hors ligne

 

#12 27-12-2012 12:35:23

bakura
Administrateur
Date d'inscription: 30-01-2010
Messages: 353

Re: Votre avis sur le squelette ZF2

Salut,

C'est une très mauvaise idée ta simplification de structure, car elle casse énormément de choses. Il y a une raison pour laquelle le squelette d'une application ressemble à ça :

config // Config de l'application
module // Liste des modules
     Application // module nommé "Application"
          config // Config du module
          src // Sources du module
                Application // Répétition du nom du module
                     Controller
                     Entity
                     Form
                     ...
          view // Vues du module



En fiat, Zend Framework 2, comme beaucoup d'autres frameworks PHP, suit les conventions PSR-0, 1, 2. Les normes PSR-1 et 2 sont des normes de codage (règles de nommages, règles d'indentation...). Quant à PSR-0, elle définit une structure dans le système de fichiers permettant de gérer l'autoloading des classes.

Autrement dit, composer (le programme de gestion de dépendances que quasiment tout le monde utilise maintenant) va assumer que tes modules suivent la convention PSR-0. Or, en modifiant ta structure comme tu le fais, tu n'es plus PSR-0, et l'autoloading ne marchera plus "par défaut" (il faudra que tu définisses toi même l'autoloading, ce qui est faisable mais qui est franchement embêtant sachant que ça peut fonctionner sans rien faire).

Bref, la structure te paraît peut-être étrange mais il y a évidemment une raison derrière, en l'occurence des conventions qui sont maintenant relativement bien suivies par la communauté PHP, et de plus en plus de bibliothèques/frameworks assument que ton code utilise cette convention. Donc je te conseille vraiment de pas trop t'amuser à modifier cette structure sous peine de jolies prises de tête à comprendre pourquoi ça marche pas.

Les évènements disponibles par défaut... Tu as lu mon message précédent ? Je t'ai donné un lien (http://zendframework2.de/en/cheat-sheet.html) qui définit la plupart des évènements levés par le framework et à quel moment.

Tu as également ce lien qui te donne une liste non exhaustive des différents évènements : http://akrabat.com/zend-framework-2/a-l … f2-events/

Hors ligne

 

Pied de page des forums

Propulsé par PunBB
© Copyright 2002–2005 Rickard Andersson
Traduction par punbb.fr

Graphisme réalisé par l'agence Rodolphe Eveilleau
Développement par Kitpages