Moi je pense que c'est juste pas assez documenté. Pour l'instant l'utiliser est une perte de temps pure et simple.
La communauté n'est pas assez grande autour du framework pour qu'on se débrouille bien à l'heure actuelle.
Version imprimable
Moi je pense que c'est juste pas assez documenté. Pour l'instant l'utiliser est une perte de temps pure et simple.
La communauté n'est pas assez grande autour du framework pour qu'on se débrouille bien à l'heure actuelle.
D'accord la dessus, mais bon ca va venir il faut pas s'inquiéter.Citation:
Envoyé par Nek.dev
Absolument pas d'accord. Il faut tellement de temps pour être à l'aise avec un framework de cette taille, commencer maintenant n'est pas du tout une perte de temps. Car si la documentation ne traite pas encore tous les points délicats, elle traite tous les points de base qu'il faut maitriser parfaitement avant de passer à la suite. Tu as donc du pain sur la planche, dès maintenant, et du pain qui va te servir par la suite.Citation:
Envoyé par Nek.dev
Absolument pas d'accord non plus. La communauté est assez énorme autour de Symfony2. Un des des plus gros projets sur github ! Une mailing liste bien remplie avec des intervenants de qualité. Des forums qui en parlent un peu partout. Des blogs dédiés à symfony2 dans tous les sens sur le web. Etc.Citation:
Envoyé par Nek.dev
Tout d'abord la doc actuelle je la trouve plutôt complète, et y a de plus en plus de cookbook qui arrive, de plus la communauté est assez réactive, rien qu'à voir sur irc, tu pose une question et hop tu as généralement ta réponse rapidement. Le code source est quand à lui bien fait ce qui permet de se plonger dedans pour essayer de mieux comprendre certaine mécaniqueCitation:
Envoyé par Nek.dev
hello,
suivant la ml depuis quelque temps maintenant, j'aurais tendance à dire, que les problèmes simple sont résolus rapidement, mais les trucs compliqués, sa reste un peu au petit bonheur la chance.. Hors comme c'est un framework taillé pour faire des gros projets, on aura nécessairement des cas qui sorte des sentiers battus, du cas d'école de blog etc Donc c'est d'autant plus important de pouvoir trouver des réponses à ce genre de questions.
Sauf si bien sûr on à de l'argent à claquer dans les services proposés par la société sensio.
Par contre :
Moi j'ai l'impression, mais je ne dois pas assez le pratiquer, que la DI à tendance à rendre les interactions entre les classes plus confuses.Citation:
Le code source est quand à lui bien fait ce qui permet de se plonger dedans pour essayer de mieux comprendre certaine mécanique
fin bon, quand je vois qu'il faut activer, at least, 500 niveaux de récursion, je me pose des questions. Vu sur la ml ce jour.
a+
bah je trouve pas que le DI rends les choses plus confuse, limite plus clair une fois bien assimilé le principe ( le fait que je sois encore étudiant et que c'est une notions vu en cours de c# ). Après pour les choses compliqué c'est normal que l'on trouve pas encore les ressources le framework est encore jeune
je préfère qu'il y ai un livre car ça empêche effectivement de se dispercerCitation:
Envoyé par johnny3
mais j'attache un point d'honneur au tuto pratique à la jobeet car un exemple ça vaut 100 fois mieux qu'un long livre (#discours) et ça a le mérite de te rendre opérationnel assez rapidement :ccool:
Bah personnellement je trouve que la docs sous sa forme actuelle est beaucoup plus pratique et agréable a utiliser que pouvait l'être jobeet par exemple, un tuto tu finis vite par te perdre. De toute façon il est plus logique que sur le site officiel il y ai la doc sous sa forme officiel, et que l'on va trouver une multitude de jobeetlike sur le net
J'ai commencer Symfony 2 il y a 15 jours apres 6 mois de CodeIgniter, je vois effectivement une grosse différence et aussi une grande éfficacité quand on a assimiler le concept, je doit etre a 10% de ses fonctionnalités mais bon je triffouille et je trouve des trucs :)
La doc j'aime pas trop sa présentation m'enfin google m'aide les 3/4 du temps.
:cry:
Voilà j'ai voulu développer avec symfony2 un site tout simple, mais je me rend compte que je perd énormément de temps à chercher des infos, les 2 tutos de Jérome Laplace m'ont bien aidé au début, mais maintenant c'est une catastrophe, je perd beaucoup de temps, je pensais que j'allais en gagner si j'utilisais un framework plutôt que tout développer en php, mais non c'est le contraire.
Doctrine2 est bien mais il prend pas en compte toutes les requêtes, donc utiliser sql natif (21/2 journée pour trouver les infos et que ça marche), ...
Twig est lui aussi limité et je n'arrive pas à utiliser des fichiers php ou html, car il me réclame des template twig ...
Donc pour l'instant je termine ce site et je repars en pur php, on verra peut-être plus tard si je m'y remets.
Il faut plusieurs mois pour prendre en main un framework. Pour Symfony2 c'est même plus global, il introduit des concepts (design patterns notamment) qui étaient peu connus des développeurs PHP, provenant du monde des langages purement objet (Java).
Le tout fait qu'il y a beaucoup de choses à comprendre/assimiler, donc plus de temps. Je dirais que pour un site perso, tu t'en passeras très bien.
Pour travailler en entreprise, l'utilisation d'un framework apporte une chose souvent négligée mais d'une importance immense : une norme de codage, des bonnes pratiques, une philosophie commune aux développements...
Et si tu baignes entre les 2 (perso et pro) : Symfony2 pour les devs pro ou gros projets en général, Silex (framework plus léger s'appuyant sur des composants de Sf2) pour les plus petits projets => tu mutualises ton temps d'apprentissage du framework.
Et sinon, quel type de requête SQL n'arrives-tu pas à faire ? Comme ça, par curiosité...
Tout à fait d'accord avec ce qui est marqué au dessus.
Symfony2 oui, mais Doctrine2 ... ou veulent-ils en venir ?
Le systèmes d'annotation me pose aucun problème. Cependant, pour quoi faire ?
La doc est tellement pauvre et n'explique que la base.
Dès que l'on fait une application complexe, aucune explication sur la méthodologie.
...
- Comment faire une requêtes pour vérifier un lien manytomany ?
- Comment éviter de faire des requêtes dans la vue puisque les annotations ne permette plus de faire suivre les requêtes(ex: $user->getClientActifs())
- ...
Bon c des questions cruciales qui me bloque des le départ et qui sont pourtant si importantes! Merci symfony2, doctrine2 tu repasseras ...
Sa sent la formation bien chère sa !!
À qui le dis-tu.Citation:
Envoyé par pingolitipus
Nous avons actuellement choisi Symfony2 pour une application représentant 6 mois de développement à 5 programmeurs (donc pas un blog), et les critiques que tu fais, nous les vivons.
1) Doctrine2 est très limité pour les applications d'envergures (je parle de fonctionnalités), ou alors la documentation est incomplète.
Il y a beaucoup de relations complexes qui ne sont pas bien expliqués dans la documentation de Doctrine2. La plupart du temps, nous devons choisir des compromis qui nous empêche d'avoir une Seconde Forme Normale ( pas 3 ou 4, DEUX !) dans notre base de données.
2) Les messages dans les exceptions sont imprécis
Les messages d'erreurs que retourne Symfony2 ou Doctrine2 sont très loin d'être explicite. Quand on a plusieurs dizaines d'entitées, et qu'on a une erreur telle que:
--> Un nom de colone était invalide dans la configuratoin de mapping d'une des entitées.Citation:
[Doctrine\DBAL\DBALException]
Unknown column type requested.
ou encore:
--> Celle là je ne m'en souviens pas, mais bon, je vous laisse deviner, c'est clair après tout non ? :roll:Citation:
[ErrorException]
Notice: Undefined index: MyVendor\MyApp\GeoBundle\Entity\Address in /Users/fmaz/Site/vendor/doctrine/lib/Doctrine/ORM/Mapping/Driver/AbstractFileDriver.php line 121
ou encore:
--> Le nom d'une colonne de discrimination avait une erreur de syntaxe dans la configuration du mapping.Citation:
ErrorException: Notice: Undefined index: in /Users/fmaz/Site/vendor/doctrine/lib/Doctrine/ORM/Internal/Hydration/SimpleObjectHydrator.php line 92
On la trouve pas drôle de passer 3h à chercher d'où ca peut venir faute de détails pertinent.
3) La documentation est incomplète
Un exemple simple, on nous explique bien comment accéder au dependency injection container, ou au doctrine entity manager. Sympa $this->truc, $this->machin, c'est ultra simple! Tant et aussi longtemps qu'on est dans le cadre bien défini d'un controlleur qui extends la classe de base Controller de symfony2.
Et quand on fait des test unitaire ou fonctionnels, on fait comment pour accéder ? C'est là qu'on se rend compte que la mécanique interne est bien peu expliquée. Alors on reverse-engineer pendant des heures. Ouf.
Bref, ce qu'il demeure à améliorer pour Symfony2 et Doctrine2 c'est:
- Des erreurs précises et utiles au développeur.
- Une documentation plus complète avec des exemples concret et complet.
Sinon, le framework est solide et professionnel, ca fait du bien de voir qu'enfin le monde PHP se rapproche du niveau de développement qu'il peut-y avoir en Java (par exemple).
La question ne m'étais pas adressée, mais j'ai formulé la même plainte, alors voici la justification :p (je vulgarise mon exemple)Citation:
Et sinon, quel type de requête SQL n'arrives-tu pas à faire ? Comme ça, par curiosité...
J'ai 2 tables:
Code:
2
3
4
5
6
7
8
9
10
11
12
Et j'ai évidemment 2 classes: Address et personAddress. ( J'ai aussi businessAddress, organisationAddress, etc... mais on gardera que 2 tables/classe pour l'exemples)
Une adresse peut exister par elle-même, sans être une personAdress.
Une même adresse peut à la fois être utilisée comme personAddress et autre ( businessAddress, etc.. )
Du coup aucune des 3 stratégies d'inheritence proposée par Doctrine2 ne peut satisfaire la réalisation de ces contraintes en respectant la seconde forme normale ( entre autre: ne pas avoir de duplication de données )
Au fait, si jamais tu peux me donner tord et possède une solution, je suis plus qu'à l'écoute ;)
Salut FMax,
Je te sens remonté :) Je comprends un peu ton emballement, j'ai également passé pas mal de temps (je ne dirais pas perdu vu que c'est en même temps de l'apprentissage. doctrine2 n est pas la mise a jour de doctrine1).
Concernant ton soucis, qu'en est il de cette configuration-ci?
Un résumé de tes tables:
Dans ton entité Person:Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Dans ton entité personAddress:Code:
2
3
4
Ca donne ceci:Code:
2
3
4
5
6
7
8
9
10
11
Code:
2
3
Hehe, salut RapotOR :)
Remonté, moi ? Bah, juste québecois (donc direct).
Ce que tu propose, c'est la première chose que j'ai essayé, mais c'est très peu pratique au niveau du code, puisqu'il n'y a aucune raison pour qu'il faille faire un getAddress() sur un objet qui est déjà une adresse ! Il faudrait alors que je fasse une tonne de méthode dites "proxy", ce que phpcpd n'aimera vraiment pas (et moi non plus d'ailleurs). ou alors des méthodes magiques, mais dans ce cas c'est phpunit qui ne sera pas content :lol:
Le problème c'est qu'en fait, personAddress est un "trait" de Address. Les aspects n'étant pas vraiment disponibles en PHP 5.3, nous avions opté pour l'héritage, ce qui permet d'avoir les méthodes d'accès de Address dans personAddress aussi.
Sauf que l'héritage que Doctrine2 propose est une horreur du point de vu des bonnes pratiques dans la conception des bases de données; elle cause littéralement des duplicatas de données !
J'ai d'ailleurs posté sur la mailing list de Doctrine, de même qu'une question sur stackoverflow, mais il semble vraiment que ce que je cherche à faire ne soit pas supporté, puisque toutes les alternatives proposés démontre des failles majeurs au niveau des bonnes pratiques -- soit du coté de PHP, soit du coté de la base de données.
Au final peut-être que les ORM sont d'avantage utile pour les petits projets sans complexité au niveau de la gestion des données que pour les projets d'envergure réelle ?
De mon experience, les ORM sont effectivement limités pour les grosses applications. Il faut user de bidouille en bidouille. C'est de plus en plus l’idée du "je programme avec l'orm mais ne sais pas ce qu'il se passe en bdd".
Je comprends ton soucis du getAdress().
Il est effectivement possible de rajouter des getter/setter dans personAdress pour acceder plus simplement à Address.
Ce n'est pas vraiment de la duplication de code.Code:
2
3
4
5
Citation:
Envoyé par RapotOR
Si j'ai 10 types d'address, dans les 10 objets ( personalAddress, businessAddres, organisationAddress, etc...) je vais devoir avoir l'ensemble des méthodes proxy.
As moins que je les place dans un objet abstrait, et que mes type d'adresses héritent de cet objet. Mais effectivement, on tombe dans le monde de la bidouille :p
Bref, on commence à être pas mal hors-sujet, mais tout ceci pour dire que l'ORM est beaucoup moins génial qu'il ne semble l'être lorsqu'on nous le présente.Code:
2
3
4
5
6
7
8
9
10
Je n'ai jamais utilisé l'héritage d'entités au niveau du modèle. La doc laisse entendre que le "Class Table Inheritance" serait le plus proche de ton cas... Mais cela impose d'avoir un champ discriminant côté Address, ce qui t'empêche d'associer une adresse à plusieurs classes enfant => aucun intérêt...Citation:
Envoyé par FMaz
J'avoue que ce 3e type d'héritage ne semble pas remplir ses promesses 8O
A part une relation ManyToOne côté classe enfant et effectivement des méthodes Proxy pas très avantageuses, je ne vois pas de meilleur compromis :aie: Je préférerai toujours avoir un modèle de données conceptuellement bon et un code qui l'est un peu moins, mais ce n'est qu'un point de vue personnel.
Perso j'ai exclu les entités de l'analyse PHPCPD sur mon serveur d'intégration continue... Je m'en remets à mon sens de la rationalité :mouarf::oops:
Vu le nombre de type de données différentes il est peut-être possible d'envisager des outils différents que l'ORM pur et dur...
Il existe les bases de données non structurées, tel mongo, qui permettent de bien gérer ce type de cas, au prix d'une remise en cause importante des habitudes de développement.
Si non il existe aussi un bundle, metastaz, qui permet de simuler des objets dynamique dans une base structurée. Ceci déstructure le modèle objet, mais permet de répondre plus simplement à ton type de cas.
Dans ces deux cas, il peut aussi être intéraissant de passer par un moteur d'indexation externe (SolR ou ElasticShearch).
j'ai commencer utiliser symfony 2 il y'a de cela 2 mois.Mais j'ai beaucoup aimé .Sa combinaison avec le moteur de template twig lui donne une force énorme .la documentation est bien faite vous trouverez sur http://symfony.com/
Bonjour,
Je débute avec le couple symfony2/doctrine2.
Je n'ai pas d'expérience avec les ORM.
Je me trompe peut être mais je pense qu'il faut "oublier" la base de données et pour la conception il ne faut plus penser Merise mais penser UML.
La base de données étant là seulement pour sérialiser nos objets.
Bonjour,
Je ne développe pas sur sf1.4 ni sf2 mais j'ai côtoyé des développeurs chevronnés sur ces frameworks et voici ce qu'il en est ressorti de nos discussions : la version 2 est partie royalement sur les traces de Java sans bénéficier de l'environnement Java. Le framework est complexe à souhait et la courbe d'apprentissage du coup est trop longue à leur yeux. Les performances en natif sont très très mauvaises. Il faut sérieusement s'équiper d'outils tiers pour atteindre des performances acceptables.
Le gros point noir à leur yeux c'est Doctrine 2, à tel point qu'ils ont décidé de le virer. Il m'ont dit l'ORM c'est déjà pas top mais en PHP c'est le mal.
Le point positif : Twig, ils ont été tous agréablement surpris.
Donc comme toujours y'a du bon et du mauvais, mais globalement l'impression que j'ai eu était qu'ils avaient été déçus par le virage pris par Symfony.
L'environnement technologique autour de PHP n'est pas du tout adapté à ce genre de framework tout-en-un.
@rawsrc
Un peu rapide l'analyse peut-être.
Il est sur que Symfony2 n'a rien à voir avec symfony 1. L'évolution est forte.
Par contre le framework est bien réfléchi, il est costaud, rapide et adapté aux gros projets comme aux petits.
L'apprentissage est trop long ? C'est simple à dire, mais difficile à démontrer dans un sens comme dans l'autre. Je ne pense pas que, pour un développeur qui connait bien PHP, l'apprentissage, puis la maîtrise, soit plus longue que pour un Zend. Est-ce trop long ? Chez nous l'apprentissage se fait "à la volée" et l'équipe fonctionne très bien sur Symfony2.
Il faut s'équiper d'outil ? Quels outils ? Où ? Pour l'exécution du code ? Pour le développement ? C'est sur, il faut un micro, un EDI, une connexion internet pour commencer à développer, mais ceci me semble nécessaire pour tous développement web !
Doctrine2 est une évolution encore plus forte, une révolution serait plus adapté. Mais Doctrine2 n'est pas le seul ORM utilisable avec Symfony2, d'autres existent et fonctionnent parfaitement. Le choix, ici, a été fait d'utiliser Doctrine2, au niveau des performances d'utilisation il n'y a pas photo. Même si l'appropriation et la bonne utilisation de l'outil est un peu plus longue. Seul bémol, l'utilisation de Doctrine2 avec des bases de données nosql, tel que Mongo qui n'est pas du tout optimisée.
Pour Twig, je ne peux que confirmer, excellent outil.
Il est sur qu'un développeur qui à beaucoup investi sur symfony 1 et se retrouve du jour au lendemain confronté à un Symfony2 et un Doctrine2, où il ne pourra absolument pas compter sur les "investissement" en formation déjà réalisé est un choc important. Mais cela en vaut réellement le coup pour quelqu'un qui débute.
@david42
Il est évident que l'analyse va partir plutôt du modèle objet que du modèle de la base de données. Mais il ne faut pas oublier que cela va ce terminer par une base de données sql, et que c'est cette base qui sera, in fine, interrogée. Il est donc important de bien prendre en compte la structure sql qui sera générée par le modèle objet, pour que celle-ci respectent les précepte de bon fonctionnement (et les formes normales). Un peu un double travail, mais le jeu en vaut la chandelle.
A savoir qu'il y'a deux choses dans Symfony2, les composants et le framework
Personne n'est obligé d'utiliser la version du framework dite "standard" , avec tout les composent nécessaire pour faire un site rapidement, (dont Doctrine2), on peux aussi partir sur du Propel, et rien n’empêche d'utiliser le DBAL seul.
Pour utiliser les composents comme ont le souhaite on peu créer sont propre Frameworks autour, je conseil à tous de lire les fameux articles "Create your own framework... on top of the Symfony2 Components" sur le site de Fabien :
http://fabien.potencier.org
Salut Michel,Citation:
Envoyé par Michel Rotta
je me posais justement la question, à savoir si utiliser Symfony pour un petit projet est bien nécessaire.
La question est toujours de savoir où est la limite entre petit est gros projet... (il est évident qu'on ne parle pas de site vitrine de 5 pages.)
Qu'est ce qu'un petit projet pour toi?
J'ai entendu dire qu'il est était assez difficile d'installer un projet sous Symfony sur un serveur mutualisé (ce qui suffit largement pour des petits projets).
Merci.
Pour les petits projets utilise Silex
Salut Stealth35,Citation:
Envoyé par stealth35
Qu'est ce qu'un petit projet pour toi?
A quel moment sais-tu si tu dois utiliser Symfony ou Silex?
un petit projet pour moi c'est quand y'a pas besoin d'ORM donc pas (ou peu de relation entre table), et 5 ~ 6 tablesCitation:
Envoyé par Farid63
Moi qui suis habitué à avoir ce que j'ai besoin tout de suite grâce à SPL et quelques classes statiques bien saucissonné.
Genre :
C'est léger, efficace, très intuitif mais on ré-invente la roue et ce n'est pas très bien organisé.Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Bref SF2 ça me change, j'ai l'impression d'être étriqué conceptuellement. A voir avec le temps ...
c'est naze et ça mouline
C'est vrai que SF2 mouline et contrairement aux blabla "marketing" SF2 est gourmand.
C'est le prix à payer pour adopter cette façon de développer quasi prête à l'emploi et bénéficier des nombreux bundles déjà dispo ...
Je nuancerai ta réponse : "mouline sous windows" pas sous linux. Ceci est du à l'utilisation de la fonction filemtime qui n'est pas optimisée sous windows. Après personnellement je le trouve plus rapide que symfony 1.Citation:
Envoyé par FrontLine
Je suis dessus depuis 15 jours.
L'entrée dedans est assez lourdes.
Mon taf c'est DBA/ZF mais vu le temps qu'il met a sortir autant essayé SF2.
Je n'aime pas Doctrine2, même si je reconnais la facilité une fois que j'ai accepté de ne pas faire de requête SQL, le fait qu'il fasse Six requêtes alors qu'avec une seule j'aurais l'ensemble de mes données sans pour autant passer par le pattern proxie me frustre. mais je le répète cela apporte une certaine facilité et je dirais même une souplesse.
Twig : ok je m'incline :)
Le framework en lui même pas de souci, prise en main rapide et simple.
Ce qui me manque le plus est un Zend_Validate complet, on l'attend pour la 2.1 mais je doute.
Le plus dur : mettre en place d'un coup SF2-Doctrine2-Twig.
Un espoir : Que le temps investit ne soit pas perdu.
@MaitrePylos
Le composant Validator est tout de même bien complet!
@RapotOR : essaye de valider une date !
Maintenant, je suis dessus depuis 15 jours et j'ai pas encore tout les automatisme.
@MaitrePylos
par contre, le pattern n'est pas paramétrable... donc, il faudrait utiliser DateTime.Code:
2
3
4
5
6
7
Code:
2
3
4
5
6
7
8
9
Tu peux toujours mettre le composant Zend\Validator en service. Il y a un repository sur Knp : https://github.com/KnpLabs/zend-validator
:ccool: merci
Pour le Zend\Validator, c'est beaucoup trop liés avec le framework Zend, je devrais aussi déployer
Zend\Date
Zend\Registry
Zend\Local
et j'en passe .
mdr donc juste a cause d'une fonction symfony est lent sous windows? ça tient pas debout ou alors ils ont perdu la boule.Citation:
Envoyé par bilbot
En même temps chercher à avoir quelque chose de performant en php sous windows faut pas être bien. Php n'est pas du tout optimisé sous windows. Rien qu'à voir le temps que prenne des test unitaire sous windows et les même sous linux ...
Si ca tient parfaitement debout dans le cas ou tu es en dev (usage massive de la dite fonction pour vérifier s'il faut regénérer le cache) ca rame, si tu fais un warmup et que tu désactive la regénération du cache c'est déjà bcp mieux.Citation:
Envoyé par sybil
Personnellement j'ai testé sur 2 machine quasi équivalente une sous windows et l'autre sous nux, le rapport des perf atteint facilement un facteur 100 (3s pour générer la page sous windows et 30 ms sous windows)