Philosophie RAD et utilisation de KnpRad

[lenybernard]

Philosophie RAD et utilisation de KnpRad

[juliensnz]

Au niveau de l'organisation RAD est vraiment bien foutu. Nous avons un seul bundle qui correspond à l'application et au métier. Si des outils doivent être développés et réutilisables, ils vont dans les vendors.

Il y a aussi de bonnes idées que nous avons appliqué à Davidson comme la configuration dans plusieurs fichiers.

Du côté des points négatifs : J'ai relevé des comportements étranges sur les traductions, et sur les surcharges en général. Il était par exemple impossible de mettre mes traductions en commun pour toute l'appli (à mettre obligatoirement dans le bundle App).
Autre point négatif : l'organisation différente rend l'application difficilement pluggable. Pour ajouter un bundle un peu complexe il peut y avoir des incompatibilités. Il faut sans arrêt convertir les chemins de doc pour les faire correspondre à ceux de RAD, quand on rencontre une erreur on se demande toujours si ça vient pas de ça...

Pour moi ce qu'on applique en ce moment est un bon entre-deux : config dans des fichiers séparés mais pour le reste on garde l'organisation standard.

Nb : L'experience que j'ai eu de KnpRadBundle date de l'année dernière et j'étais débutant à l'époque.

J'ai essayé de l'utiliser lors de mon premier projet mais pour débuter c'était pas pratique car je ne connaissais pas le framework et les ressources sur le web ne correspondait plus à l'architecture de mon application j'ai donc abandonné. Par contre j'ai relu la doc il y a un mois ou deux et j'ai noté plusieurs choses sympa notamment :

• Template creation
• IS_OWNER Voter
• Unsafe methods handling through link

Après perso je préfère conserver la structure standard, en ajoutant les fonctionnalités cool du RadBundle.

Pas la même RAD que la KnpLabs mais à voir : http://blog.liip.ch/archive/2013/09/24/symfony-rad-edition.html