Reprise du message précédent :
D'après ta signature je lis que tu bosses pour Sensio Labs, ça doit être sympa de bosser sur un truc récent et de ne pas s'encombrer de la maintenance de vieux bousins en PHP 3 ou 4...

Pour en revenir à ce dont on parlait, normalement les macros devraient suffire, cependant je découvre toujours comment ça marche, je ne me suis pas encore approprié complètement la logique de fonctionnement de SF2.

Après, ce serait plus pour une question de curiosité personnelle, mais c'est toujours intéressant de savoir comment faire une extension Twig...
Et encore, Il y a les extensions, les Nodes, j'ai pas encore tout capté mais ça viendra en temps voulu

De ton ressenti par rapport à toutes les façons de configurer une application (Kernel, Bundles, etc...), tu es plus sur le PHP, le YAML, le XML ou les annotations ?

J'ai la chance aujourd'hui de travailler sur un projet nouveau, innovant, qui utilise Symfony2 oui. Mais tu sais, ici c'est comme partout, on a des projets pas géniaux.
Typiquement, il y a à peine quelques mois, j'étais sur un projet qui a un frontend en symfony 1.0, un backend ayant des parties en php4 et d'autres parties en symfony 1.0, le tout bricolé via un front controller pour que tout tienne ensemble    
 
Faire une extension Twig est un exercice relativement simple, mais ça dépend ce que tu as besoin de faire. En gros la plupart du temps, une extension Twig est juste constituée d'une classe. Quand tu veux rajouter quelques filtres (syntaxe '|'), quelques fonctions, ou quelques tests (syntaxe "is blabla" ), c'est très simple.
 
La difficulté intervient quand tu souhaites faire des trucs un peu complexe, par exemple introduire un nouveau tag, genre le form_theme. Car là, tu es obligé de jouer avec les parser et lexer de Twig. C'est tout de suite bien plus dur à mettre en oeuvre.
 
Pour les différentes façon de faire de la configuration nous ici on utilise presque tout, mais dans des cas bien précis :
- Entités doctrine2 (mapping + contraintes de validation) : Annotations
- Routing : YML
- Services : YML pour des services internes à un projet, XML pour des services dans des bundles destinés à être publié.
 
Il n'y a que la configuration en PHP pur que l'on n'utilise pas.

Je suis parti à peu près sur le même modèle en fait
 
J'ai une autre question qui commence à trotter dans ma tête...
En fait je me demande comment sont gérées les connexions SQL master / slave.. L'idée, c'est que si la connexion par défaut ne fonctionne pas, de switcher sur une seconde.
 
De ce que j'ai vu ça n'a pas l'air d'être prévu, mais là aussi je peux me tromper. Avant de me lancer dans une étude plus approfondie, je voulais voir si tu avais déjà été confronté à ce genre de problématique.
 
Grosso modo je pense que ce qu'il faut faire, c'est un service tagué kernel.event_listener de type kernel exception, qui gèrerai les exception PDO et qui s’occuperait de faire la bascule.
 
Le truc c'est que je ne suis pas sur d'avoir la bonne approche...
 

Je n'ai jamais eu ce genre de problématique.
Les cas de multiples bases de données que j'ai eu, c'était que le modèle était réparti dans différentes bases de données par exemple. Et ça je crois bien que ça devrait être pris en charge.
 
Typiquement pour ta problématique, nos ingénieurs systèmes et réseaux ont un avis bien tranché sur la question : Ce n'est pas à ton application de gérer une bascule. C'est une problématique pûrement d'infrastructure. Pour eux, ton application doit interroger toujours la même IP, et c'est la machine présente sur cette IP qui doit être capable de savoir si elle a un noeud SQL mort, de passer sur un autre, etc.

C'est ce que j'ai essayé de faire passer... C'est ce que j'avais demandé... Mais on ne m'a point écouté...

Supposons donc qu'il faille que je mette en place ce mécanisme au niveau applicatif, j'ai vu qu'il existait un plugin, mais pour sf1.x
 
Penses tu que ma démarche serait correcte ou aurais-tu une approche différente ?

Personnellement j'aurais eu une autre approche.
 
Dans Doctrine, tu as une classe Connection qui représente une connexion à la base de données.
Personnellement j'aurais plutôt vu le fait d'étendre cette classe, sauf qu'elle contiendrait en elle-même plusieurs connexions. (à voir après comment pour configurer ces connexions via les fichiers de conf)
Ensuite dans cette classe, surcharger les méthodes type connect (essayer de se connecter sur la 1ere, si la connexion foire, on essaye la seconde, dès qu'une est up on la garde), les méthodes comme executeQuery, beginTransaction, commit, rollback, etc, pour être effective sur la bonne connexion de façon transparante. Comme ça, tout est transparent.
 
Par contre si ta base tombe pendant une requête (http), je doute que tu puisse facilement implémenter un mécanisme qui permette de switcher de connexion et de reprendre là où tu en étais de façon précise.

J'y avais pensé, mais la raison pour laquelle je n'avais pas retenu cette solution, c'est qu'étendre la class de connexion de Doctrine n'est pas compliqué en soit, mais après de faire en sorte qu'elle soit utilisée par le moteur, bref, de référencer cette surcharge.
 
De ce que j'ai vu, il suffirait de modifier la valeur du paramètre doctrine.dbal.connection.class dans le fichier dbal.xml du DoctrineBundle.
Mais là encore, vu qu'il n'y a pas encore de doc là dessus, je ne suis pas sur qu'il n'y ait pas d'autres modifications à effectuer...
 
M'enfin, rien n'empêche de tester

J'ai testé, et visiblement, ça ne marche pas... Même en mettant n'importe quoi dans ce paramètre, ma class n'est pas appelée

Chez moi ça fonctionne.

Fichier app/config/services.yml

parameters:
    doctrine.dbal.connection.class: Toto

Et si je fais un "app/console container:debug" j'ai bien une ligne qui indique :

Ma connexion par défaut est donc bien du type Toto. S'il ne se passe rien c'est peut-être que ta page ne fait aucune requête en base de données ? Les services sont instanciés à la demande uniquement, donc si tu ne fais aucune requête, il n'essayera pas d'instancier la connexion, et donc tu n'auras pas d'erreur comme quoi Toto est un type indéfini.

Edit : Sinon à part ça tu as bien saisi le principe de l'injection de dépendance. Tu peux la plupart du temps remplacer très simplement une classe par une autre juste avec une petite conf qui va bien. Et c'est vraiment THE feature je trouve.

Hé hé ! Bien essayé, mais je me suis évidemment assuré de me mettre dans le contexte qui correspond à ce que je cherche à faire

Pour le moment, j'ai juste provoqué une PDOException sur la connexion en BDD, donc de ce côté là je suis sur que j'essaye bien de créer une connexion

Par contre je me suis surement planté sur la configuration.
Et il y a un autre élément de taille à prendre en compte que j'avais légèrement zappé, c'est que là c'est un version beta 4... Donc c'est peut être normal que ça ne marche pas chez moi...

Il faudra que je teste ça depuis la dernière version en date, autrement dit la version stable...

Edit:
Non, que ce soit sur la beta 4 ou la stable, ca ne veut pas marcher...
Tu n'as pas déclaré un service ou fait autre chose ?

Moi je t'avoue que je ne me suis pas mis dans un contexte qui correspond à la situation. J'ai supposé en affichant la liste des services que ça donnerait le résultat attendu.
 
Est-ce que quand tu fais le app/console container:debug tu obtiens la même chose que moi ?

Alors, oui, maintenant j'ai bien Toto qui remonte (Oui j'ai repris ton exemple ).

Par contre après, niveau interface, il se trouve que la class Toto je ne l'ai pas déclarée, je m'attendais donc logiquement à avoir une erreur de type "class not found"... Mais que nenni !

Je reste sur la PDOException que j'avais au départ

Edit: je t'ai envoyé un MP

Edit 2 : Voilà ce que ça me retourne :

Tu l'auras surement compris, c'est à terme censé faire tourner un applicatif audiotel.

Ok, alors en fait, j'ai été fouiner dans le code de doctrine avec Fabien, il se trouve qu'il se fou complètement de ce qu'on lui donne dans ce paramètre. J'avais supposé à tord que si l'injecteur de dépendance affichait correctement le changement, c'est que ça serait bon    
En fait, le code concerné par la création des connexions est directement dans doctrine et non dans le DoctrineBundle (ce qui est normal puisque doctrine est autonome) et donc quand il créé sa classe de connexion il n'a donc pas l'injecteur de dépendance pour récupérer le type souhaité, il prend son type par défaut : Doctrine\DBAL\Connection.
 
Heureusement pour nous, les petits gars qui l'ont codé ont quand même pensé à pouvoir changer cette classe via la configuration de doctrine.
 
Le paramètre "doctrine.dbal.connection.class" sera donc supprimé dans la prochaine release normalement, et en fait le bon moyen pour définir la classe utilisé c'est dans app/config/services.yml, en fait sur la déclaration de ta connexion il faut faire :

Tout s'explique !
je testerai ça demain, j'en serais aussi venu à fouiller dans le code de doctrine à un moment ou à un autre

En tout cas, ce framework me plait vraiment ! Au delà du système d'injection de dépendance fichtrement bien pensé, ce que j'adore surtout,  c'est qu'on est sur un vrai modèle objet exploitant vraiment le potentiel de PHP 5.3, plus de singleton (Amen !! ), ni de gros array qui passent on ne sait quoi et qui ne sont pas filtrés...

La plupart des gens qui dénigrent PHP le font parce qu'ils pensent (de ce que j'en ai entendu en général) qu'un langage aussi permissif conduit inévitablement à des prises de liberté dans la façon de coder (On peut pas accéder à une variable ? Allez on fait un bon gros global bien dégueu ).

Bref en tout cas Symfony2, Doctrine 2 et Twig, j'adore !
C'était un boulot titanesque de repartir "from scratch", je regrette un peu de ne pas avoir pris part à sa conception et son développement, car ça, pour le coup ça m'aurait grave intéressé (En même temps, je ne connaissais pas Symfony avant)

Faut sacrément être con pour penser ça, vu que c'est carrément une insulte à tous les devs PHP

PHP conduit naturellement vers un code quick & dirty, par contre, ça c'est vrai

Tant qu'on y est : ceux qui sont passés de Symfony 1/Doctrine 1 à Symfony 2/Doctrine 2, qu'est-ce que vous voyez comme%

Il faut deviner la question ?  

T'inquiètes que quand j'ai entendu ça, je me suis tout de suite senti insulté
Les personnes auxquelles je fais référence développent sur des langages plus bas niveau que PHP (Surtout C et C++) Et que l'un d'eux a récemment été contraint de faire du PHP (Je dis "contraint" parce qu'on lui a pas laissé le choix) et qu'il m'a fait part de son ressenti...

Edit: enfin pas insulté mais presque vexé qu'il pense ça des dev PHP

Tin, connexion pourrie
Je la refais

---

Tant qu'on y est : ceux qui sont passés de Symfony 1/Doctrine 1 à Symfony 2/Doctrine 2, qu'est-ce que vous voyez comme inconvénients ? (les qualités on s'en fout, on connait )

L'absence de fixtures en YML ?
L'absence de behaviours Doctrine ?
etc ?

Merci d'être francs, une réponse du type "rien de me dérange" ne me satisfait pas Sauf à la rigueur de la part de Tirkyth qui a un contrat à respecter

Te dire en face qu'un dev PHP est forcément mauvais, c'est quand même pas loin de l'insulte quand tu en fais partie... Allez, une insulte naïve au mieux.

Je réfléchissais, et là dessus je me suis dit, oui effectivement ça résout bien des problèmes mais voilà : dans mon cas, il y a plusieurs applicatifs sur cette plateforme, je veux dire par là, chacune dispose de son propre kernel. Cependant, chacun des applicatif utilise en plus de son propre bundle, un bundle central commun (je rentre pas dans les détails, ce serait trop long...)
 
Et ce qui me gène un peu dans cette solution, c'est que du coup ce paramétrage devra être fait dans chacun des projet en cours et à venir, dans chaque fichier services.yml de chaque applicatif, alors qu'en passant par un event listener déclaré dans le bundle central permettrait une totale transparence.
 
Donc, je me dis qu'il doit surement y avoir une solution intermédiaire, du genre lors de la compilation du cache du projet, on adapterait le container depuis la méthode build du bundle

Attention, il ne faut se méprendre, ce qui est critiqué c'est le langage avant tout, bien sur étant dev, on se sent visé aussi c'est sur

Ben, il dit qu'avec un langage pareil on ne peut que devenir un mauvais dev, en gros
Donc indirectement, un peu quand même, enfin bref, au pire c'est une insulte purement professionnelle
 
Sinon t'as pas fait de sf1 avant, toi ?

nan Mais déjà j'ai un problème dès lors qu'on parle de singleton... J'ai un peu les nerfs contre les singletons

[hs]
Le mec qui a fait le JS de la page de réponse à un topic à du laisser un p'tit bug qui fait monter le CPU à 100% dès lors qu'on commence à écrire, et donc fait chauffer le portable et descendre la batterie :s
[/hs]

L'absence de fixtures en YML personnellement ça m'est égal. On peut faire des fixtures c'est le principal je pense. Les faire en PHP plutôt qu'en YML c'est un détail je trouve.
 
Même si j'ai un contrat à respecter je peux être franc : L'absence des behaviors dans Doctrine2 est une énorme point négatif qui doit être sérieusement considéré.
Il existe quelques libs et bundles qui essayent de les réimplémenter oui en effet, mais pour avoir testé, actuellement ça ne fonctionne juste pas. Enfin, pas tous. J'ai bien le Sluggable, Timestampable qui fonctionnent, mais le Translatable et Versionable non. Alors pour un projet qui doit être en plusieurs langues, comme c'est très souvent le cas, on en vient à implémenter à la main la gestion des traductions.   . Nous justement actuellement on bosse sur un truc multilangue, avec gestion de workflow et versions pour les contenus.
Et on est un peu dépités du coup.
 
Dans l'ensemble, Fabien a l'air vraiment très très déçu de Doctrine2, et on l'est tous plus ou moins ici. Pour ne rien cacher, on est en train d'évaluer la possibilité de laisser tomber Doctrine2 et d'utiliser Propel 1.6.
 
Pour moi c'est vraiment le gros point noir, je n'en vois pas spécialement d'autre.

Question : qu'appelles tu les "behaviors" ? D'après ce que tu en dis, je crois avoir compris, mais j'en suis pas vraiment sur...

En fait en doctrine1 il y a ce qu'on appelle des behaviors que tu peux mettre sur ton modèle. Ce sont des comportements, entièrement automatisé pour avoir certaines fonctionnalités.

Si tu déclares une entité comme étant "Timestampable", elle enregistre automatiquement sa date de création et de dernière modification dans des colonnes de la base de données, sans que tu aies besoin de déclarer ces colonnes ou de faire le code qui se charge de mettre à jour les valeurs contenues dedans.

Sluggable, permet à définir un certain nombre de colonnes qui serviront à créer le slug de l'entité, qui est une chaine de caractère valide pour les urls. Ainsi, si j'ai un Produit qui comporte une propriété "nom", alors je peux dire que Produit est Sluggable et que le slug sera composé par la colonne nom.
Ainsi, si je créé un produit ayant pour nom "Produit génial", le slug "produit-genial" est automatiquement créé. Très pratique pour faire des liens propres car le slug est unique. Si je créé un autre produit "Produit génial", automatiquement son slug sera "produit-genial-2".

Versionnable permet d'avoir un versionning des contenus de façon automatique à chaque fois que tu le mets à jour, et par défaut quand tu récupère un contenu on te donnera toujours la dernière version. Il me semble que tu as des méthodes pour te permettre d'aller chercher des versions bien précises.

Translatable te permet de définir les champs qui vont être traduits, qui sont alors déportés dans une 2ème table. Tout ça est fait de façon automatique. Selon la culture de l'utilisateur, on va chercher les bonnes traductions.

Ce sont des features que j'estime indispensables ^^ Et en Doctrine2, tout cela n'existe plus "out of the box".

OK, merci pour l'explication, c'est bien ce que j'avais compris
Et effectivement, ne serait-ce que pour les problématiques de SEO ou de traductions, ce sont de sacrées features, je trouve ça dommage qu'ils n'aient pas implémenté ça dans la version 2...

Si tu reprends pas les fonctionnalités de la version précédente, c'est une forme de régression, non ?

Ah bah ça c'est une réponse
 
Il me semblait pourtant qu'ils promettaient que l'I18n serait quand même géré out of the box sans behaviours...
 
Très bon à savoir en tout cas, tous mes projets Symfony sont I18n. Et c'est quand même un des trucs de base qu'on est en droit d'attendre d'un ORM.
 
J'ai envie de dire, c'est facile d'avoir un ORM 20 fois plus rapide quand tu lui retires la moitié de ses fonctionnalités
 

Voilà, et en plus tu peux évidemment en créer toi-même, ce qui crée une sorte d'héritage multiple dans les modèles.
 

Je trouve que les mecs de Doctrine n'ont jamais eu d'explication satisfaisante sur le sujet dans les blogs...
En gros ils justifiaient ça par la beauté du code et de l'organisation, et les perfs.
En disant "vous verrez, ça manquera pas" tout en admettant que les I18n (Translatable), elles, étaient indispensables... Et apparemment ils n'ont pas trouvé de solution de remplacement satisfaisante

C'est une question de point de vue.

On les avait dans doctrine 1, très bien ...
Pour Doctrine2, les mecs qui l'ont fait ont estimé que ce n'est pas le job de l'ORM de gérer ce genre de choses. Pour eux l'ORM doit pouvoir persister des objets en base, les récupérer, etc. Mais pas les altérer. C'est ton application qui les modifie, pas l'ORM. Alors que dans le cas des behaviors, c'était effectivement l'ORM qui les modifiait, en leur rajoutant des méthodes, des colonnes, etc.

Donc on a perdu ces features là. C'est une régression pour nous en temps que développeur, car il nous manque des features c'est sûr. Mais en effet point de vue développeur du projet Doctrine2, je pense qu'ils ne voient pas ça de la même façon.
Mais ils étaient probablement utilisateurs eux-même de leur projet, alors je me demande comment ils font pour ne pas ressentir ce manque

Vu que jusque là je n'ai pas encore eu le besoin de faire des traductions ou du versionning, j'avais pas encore tilté sur le fait qu'effectivement ce sont des fonctionnalités essentielles...
 
D'un côté c'est peut être un peu simpliste, mais ORM ça veut quand même dire Object Relationnal Mapper, et si on prend les mots tel quel, ils n'ont pas tort : ca a son sens de ne traiter que les parties relationnelles entre les objets, et puis les autres champs, ben...
 
D'un autre côté, quitte à faire une gestion en objet d'une SGBD, autant gérer tous les types de champs, là en ne traitant "que" les champs comportant des foreign keys, ca occulte tous les autres qui ont pourtant un rôle à jouer et ne sont pas là juste pour faire joli
 
Au final, je dirais que ça doit faire parti du package de Doctrine 2. Soit on mappe les SGBD sur des objets soit on le fait pas ! Là on a clairement l'impression qu'il manque quelque chose, que ça a été fait à moitié...
 
Cependant pas nécessairement intégré à l'ORM, puisque les behaviors dont il est question ne concernent pas des relations inter objets.

Attention : L'ORM gère bien tous les types de champs : autant des champs normaux que des clés étrangères vers d'autres entités.
Si tu déclare un objet Produit qui a un nom et une catégorie, et un objet Catégorie qui a juste un nom, tout cela est bien pris en charge tant que tu map bien correctement toi-même tous les champs et relations.
La seule chose qui n'est pas gérée ce sont les behaviors qui étaient capable en doctrine1, de rajouter des colonnes supplémentaires automatiquement et des méthodes sur tes objets afin de gérer toutes ces features en plus.

Je pige pas clairement pourquoi gérer l'I18n ne serait pas le boulot d'un ORM...
 
Tu peux avoir une représentation au niveau objet et une autre au niveau BDD, ça reste du mapping nan ?

Bah tu peux très bien mapper toi même ton i18n à la main. Ça t'oblige juste à déclarer une autre entité avec les bonnes colonnes, faire la relation vers l'entité de base, et ça va fonctionner.
 
Mais tu vas devoir faire les bonnes conditions de jointures toi-même quand tu voudras récupérer des contenus. Alors qu'avec les behaviors, tout ça était automatique et transparent.
 
C'est vraiment une question de point de vue tout simplement. Certains considèrent que c'est une problématique que l'ORM devrait prendre en compte, d'autres considèrent qu'avec tout ce qui est fournit (mapping, events, etc.) tu peux être capable de ré-implémenter la fonctionnalité.
 
Moi personnellement, quand je prends un framework + ORM, c'est pas pour me taper l'implémentation de ce genre de trucs que je considère comme une problématique de base.

C'est pas ça que je veux dire
 
Ce que je veux dire c'est que leur justification n'est pas tout à fait au point, je ne vois pas pourquoi ce ne serait pas le job d'un ORM de faire un mapping complexe de ce type.

Oui j'ai bien compris
 
C'est bien une question de point de vue. Moi je suis d'accord avec toi, mais eux non visiblement.
 
Enfin bref, personnellement, je teste le PropelBundle du coup  

Question philosophique
 
J'ai créé un nouveau Type DBAL, par rapport à l'architecture du projet, suis-je censé les mettre dans Acme\DemoBundle\DBAL ou plutôt dans  Acme\DemoBundle\DependencyInjection\DBAL ?
 
Et du coup une autre question concernant la prise en charge de ces nouveaux types au sein de l'application:
 
Pour le prendre en charge j'ai fait dans le fichier de config :

cependant je me suis dit que ce serait plus à sa place dans la méthode boot de mon bundle, or en faisant comme ça, j'ai une erreur fatal de class non déclarée...
 
Pas moyen de gérer ça dans le boot du bundle ?

Moi j'ai une autre question
 
Est-ce qu'il est envisageables d'intégrer les nouveaux forms Symfony2 dans un site Sf1/Doctrine1 ?

Moi je le mettrais dans Acme\DemoBundle\Doctrine\DBAL\Types    

Je pense que non. Là c'est de la conf vraiment propre à doctrine donc passer via la conf me parait la chose à faire.

Je dirais que oui, mais ça se fera sûrement pas en claquant des doigts. A mon avis ça risque d'être un chantier avec quand même du boulot.
(Soucis d'autoloading, convertir les features propres à Doctrine2 en doctrine, comment gérer l'affichage des widgets, etc   )

OK, donc je peux tout de même faire un truc à mi chemin, le rajouter lors de la compilation du cache en enrichissant le container.
Pourquoi je souhaite faire ça, parce que pour chaque kernel qui utilisera mon bundle, je vais être obligé de déclarer les types dans le config.yml...
 
Alors que le faire au niveau Bundle, c'est totalement transparent