Reprise du message précédent :

Disons que tu récupères un projet qui est déjà un peu vieux et fait à partir de CI.
Disons que bête et méchant, tu as besoin d'info, tu fais une recherche google et tombe sur la doc officielle. Qui va te donner plein d'infos super utile sur la version actuelle et pas sur des vieux trucs. Tu vas donc te retrouver avec des méthodes qui ont changé ou ont été ajoutées depuis.
Tu prends la doc php, pour la plupart des fonctions tu as droit à la version à laquelle elle a été ajoutée et un log des changements de l'API, pas chez Code Igniter. Tu prends jQuery ou mootools, tu as des liens vers les vieilles versions de leur doc. Pas chez CI.

Ouais, donc suffit de le savoir et de laisser la doc correspondant à ton projet avec le projet en question. Problème résolu

 
C'est cool à dev un plugin WP

Arrêtez d'utiliser CI pour Code Igniter, chez moi ça veut dire "Continuous Integration" et ça me trouble

 
Non mais vous savez vraiment de quoi vous parlez ?
 

 
On va surtout arrêter de parler de CodeIgniter tout court. C'était bien il y a encore un an, mais là faut vraiment penser à évoluer

 
C'est quoi le soucis ?

 
Tu trouves vraiment ça "cool" de développer un plugin wordpress quand on voit comment le bouzin est codé et comment tu dois coder ton plugin ?

 
C'est accessible pour le commun des mortels, facile à mettre en oeuvre, donc oui
 
Après, je n'ai pas dit que c'était du propre ²

Bon alors je check là la doc de SF2, ça à l'air très bien. J'vois que par rapport à mon propre FW, y'a des trucs en commun ou qui y resemblent fortement, donc la migration ne devrait être pas trop lourde à faire.
 
J'me dit même que pourquoi pas utiliser leur système de templating (twig), à voir (on peut aussi y aller en PHP direct de toute manière).
 
Pour ce qui est de l'accès à la DB, ils utilisent par défaut Doctrine. Ça marche bien, ça ? Je sais que certains d'entre vous l'ont déjà utilisé. Question perfs/flexibilité, y'a pas de probs ?

 
En-dehors du fait qu'il faut un temps monstre pour faire marcher un truc qu'on fait en 5 minutes en tapant le SQL soi-même, ça fonctionne.

Enfin c'est un ORM, quoi.

Twig est vraiment pas mal foutu
 
pour doctrine, j'ai un avis plus partagé. C'est bien dans l'immense majorité ces cas : la définition du modèle doctrine structure tes tables et constuits tes modèles php. Ca fait gagner du temps  
Les migrations entre différetnes versions de modèle sont facilitées aussi  
 
Par contre une fois de temps en temps, je suis bloqué sur un problème de requete complexe ou de perfs=> dans ca cas là , je passe en sql brut

C'est ce que j'ai cru comprendre ouais, on peut toujours passer en SQL brut dans Doctrine, du coup le problème est reglé ?

oui : http://docs.doctrine-project.org/e [...] e-sql.html

Pour forcer le traites, tu peux même utiliser  doctrine juste pour gérer tes modèles et tes migrations.

 
J'ai du mal avec les moteurs de templates, mais chacun ses goûts.
Concernant Doctrine, c'est très bien, tu génères facilement tes modèles en lignes de commandes, avec leurs relations, etc. La seule "contrainte" c'est qu'il faut avoir un schéma de base nickel, sinon tu vas galérer.
J'ai pas remarqué de soucis de perfs notoire, au pire tu utilises le DBAL quand c'est le cas.
 

 
+1

Développe.
De mon expérience ça fait perdre plus de temps que ça n'en fait gagner, pour au final devoir se taper le SQL à la main quand même si on veut des perfs correctes sur des requêtes un poils plus compliquées que select * from table.
Et je parle même pas de la lolconfig à base de commentaires @ORM qui rend le truc complètement imbitable.

 
De mon expérience c'est l'inverse

On a eu 50 fois le débat, notamment avec Skeye, y'a des bons arguments des 2 côtés

Tu as décrété que les ORM, et les fonctions magiques , c'est de la merde inutile, pas sûr qu'on arrive a te faire changer d'avis, mais bon

1/ les annotations sont un des moyens de construire ton modèle doctrine, avec le xml et le yaml. ils te permettent d'avoir AU MEME ENDROIT la définition des structures des tables et leur usage. Je trouve ça extrêmement confortable

2/ Dans un site classique il y a une énorme volume de requête qui consiste juste à aller chercher les données d'un enregistrement, a aller chercher un ses données dans une table jointe. Ce genre de truc est complètement masqué par doctrine. idem lors de la sauvegarde.

3/ les perfs : Chez moi ca marche pluôt bien. Sur la dernière appli ou j'ai utilisé doctrine, j'ai 3 requetes qui sont en SQL natif. Tout le reste fonctionne avec de bonne perfs, une fois le cache activé.
 

Bref, ça laisse du temps pour se concentrer sur les parties vraiment pénibles, tout en t'interdisant de faire des trucs non traçables ( genre modif du schéma de bdd non versionnée )

 
Twig, tous les gens qui y sont passés en sont contents.
 
Pour Doctrine, tu peux aussi aller voir du côté de Propel.
Sachant que tu peux mélanger les usages entre ORM et SQL suivant les besoins. Genre ORM pour le CRUD c'est pratique. Pour des requêtes de reporting par contre...
Je recommande plutôt Propel.

il y avait une nouvelle version de propel dans les tuyaux,non ?
j'ai pas trop suivi l'actualité, en ce moment, c'est plus backbone/leaflet/node ici

J'ai vu qu'avec Propel, tu fais un XML qui te génère une classe correspondant à ton entité. Avec Doctrine, tu crées la classe directos (avec les fameux @ORM). Dans mon FW, j'ai déjà les classes qui vont bien, ce serait peut-être plus simple pour ma migration si je devais juste rajouter les @ORM

Non, pas sûr.
Je ne comprends toujours pas ce qui peut pousser les gens à utiliser un ORM qui les force à apprendre une syntaxe spécifique, pour derrière que ce dernier fasse ce qu'ils savent déjà faire avec du SQL, et qu'ils devront de toute manière refaire eux-mêmes pour des questions de perfs ou de complexité de temps en temps.
 

 
Au même endroit, concernant les annotations, désolé mais non. Tu te retrouves au contraire avec la description de ta structure éparpillée tout au long de dizaines de fichiers...c'est strictement inutilisable, et carrément cauchemardesque à débugger.  
Et de toute manière en ce qui me concerne, considérer que la structure de la base fait partie du code de l'appli est une hérésie...mais c'est probablement très lié au fiat que j'ai de multiples applis qui utilisent la même base - dont je ne maîtrise pas la structure!
 

 
Et au moindre bug sur un cas tordu ou une erreur dans ta config de doctrine t'es parti pour une joyeuse chasse au trésor avant de comprendre ce qui se passe.
 

 
...et combien de temps passé à configurer doctrine par rapport au temps qu'il t'aurait fallu pour écrire le SQL?
Sur un projet "vierge" pour lequel on utiliserait l'ORM depuis le départ pour gérer les versions de la base pourquoi pas...je reste persuadé que les gains ne justifient pas les emmerdes, mais je comprends que ça puisse tenter certains.

Doctrine en lui même c'est vraiment bidon à utiliser, et une fois couplet au frameworks de forms de sf2 c'est tout simplement magique

Faudrait voir à changer de refrain

Vous avez essayé avant de parler ?
Les select qui se génèrent tout seuls à partir de la base, les relations qui sont directement prises en compte dans les formulaires...

C'est plus ça en fait la différence, tu pars d'une optique que la DB est l'API, avec plusieurs applis qui tapent directement dedans. Non seulement je sais pas trop si ça a jamais fonctionné (correctement tout du moins), mais ça se fait de plus en plus rare, la tendance est plus à une API service avec la DB qui est un détail d'implé du service. Donc le fait que le modèle de la DB soit géré par l'appli, ben c'est pas spécialement grave (dans cette optique là).

C'est juste une manière différente de voire la DB: garant de l'intégrité structurelle et logique des données, ou bien juste espace de stockage "stupide".

C'est ce que j'ai fait dans mon FW

Mieux vaut éviter de trop jouer avec l'héritage tout de même. Doctrine est très chatouilleux à ce niveau.
 
On va bien se marrer lorsque des gens voudront les traits dans Doctrine alors que ceux-ci ne sont pas dispo dans Java (donc rien qui corresponde dans Hibernate donc rien dans Doctrine).

oui
 

 
Bénéfice : 0. Si tu sais pas écrire un select sans ORM tu sauras pas utiliser l'ORM correctement non plus.
 

 
...et c'est presque pas horrible à utiliser sur des formulaires complexes qui vont taper dans plein de tables.

 
Pour moi tout part des données, effectivement. D'un autre coté je vois mal comment il pourrait en être autrement...les données persistent, les applis changent.

J'allais oublier sur Doctrine : pas de on update cascade et ça fait de la merde sur les enum lorsque tu mets à jour le schema de la base et que tu as changé certaines valeurs possible d'enum. Et n'imaginons surtout pas utiliser des clés primaires composées de plusieurs colonnes.
 
En ce qui concerne Twig, je n'aime pas le concept de moteur de template implémenté dans un langage fait pour les templates à la base. Mais vu que 90% des utilisateurs SF utilisent twig, dur de trouver des réponses aux questions sur le templating php de SF2, tout est à chaque fois à base de Twig. Mais le système dispo est vraiment puissant : héritage + slots = win.

Ça a pas vraiment de rapport, bien sûr que tout part des données mais données != RDBMS. Après tout, le RDBMS est lui même un service sur les données "brutes" qui pourraient tout aussi bien être stockées directement sur le FS.

Nous ce qu'on utilise à fond dans Propel c'est le Criteria (qui maintenant est amélioré avec les Query).
En gros c'est un objet qui contient ta requete et le gros avantage c'est qu'on le balade dans nos différents objets pour l'enrichir.
C'est notre query builder (on utilise très peu la partie rééllement ORM de Propel).
Et ça en SQL brut tu peux te brosser pour faire un truc clean.

Les on delete, c'est bon Les triggers ? Shit pour les clés composées
 

Ouais ça à l'air cool, vu qu'en plus c'est parfaitement extensible avec fonctions custos et tout

Je te l'accorde.
Ce que je voulais dire c'est que pour moi les données en elles-mêmes et indépendamment de l'appli/ORM/quoi que ce soit doivent déjà être structurées et peuvent avoir leur vie propre...vouloir à tout prix les lier à une appli en particulier me parait incongru, voire dangereux.

Vrai. Bon je viens de voir qu'au lieu de foutre des @ORM, on peut mettre un fichier YAML ou XML à côté, ce qui me semble plus propre

Je te le recommande, si tu tiens à utiliser doctrine.
Les @ORM c'est une des pires choses que j'ai pu voir en PHP, perso - et c'est pas peu dire.
De la logique métier dans des annotations en commentaire dans le code. Le machin est censé te faciliter la vie, pas rendre le fonctionnement du truc complètement opaque sans passer 3 jours à naviguer dans le code.

J'vais faire ça ouais. J'peux utiliser les fonctions de base côté ORM pour quick-hacker des trucs bateaux, et pour des machins plus compliqués toujours faire de l'SQL à la main.
 
Après je vois par exemple que Propel a un support natif des nested sets pour les hiérarchies, mais je ne veux plus de telle implé (que j'ai actuellement dans mon appli). C'est au final chiant pour des requêtes récursives avec des clauses ORDER un peu spécifiques, ça oblige à faire des trucs par dessus côté PHP, qui pourraient être faites en une seule requête. J'opte maintenant plutôt pour une closure table.

Et c'est le même format que pour Propel

D'un autre côté le mapping dans des fichiers séparés j'en ai fait l'expérience avec Hibernate à l'époque (avant que Java ait de vraies annotations) et c'est super frustrant, parce que tu te retrouves en permanence à devoir naviguer entre le fichier de mapping (qui en plus était obligatoirement en XML donc imbitable) et le fichier de modèle et à devoir répéter 15 fois les mêmes noms.

Après clairement ça vaut pas de vraies annotations (JPA/Hib 3) ou des objets dédiés (SQLAlchemy, DjangORM), mais je tends à préférer les "annotations en commentaires" (surtout si le parser/compilo est correctement fait et rapporte bien les erreurs) à un fichier de mapping externe, sauf à avoir une très très bonne intégration IDE, parce qu'au final c'est juste encore plus chiant.