Discussion :

[GrandFather]

Si je prend juste le fichier de config de module de l'exemple de RobAllen's, et c'est souvent son tuto qui est mis en avant pour les débutant, tu avouras que c'est loin d'être facile à prendre en main

Si c'est réellement représentatif du code de configuration d'une application Web « basique » écrite avec ZF2, il est très clair qu'ils ont foiré le principe KISS et que je vais en rester à ZF1. Et je prédis à ZF2 le même avenir radieux qu'à PHP6...

@SurferIX : de ce que je vois, ton framework suit en gros le même pattern MVC (quoiqu'il n'y ait pas dans ZF un contrôleur par vue, typiquement une vue est associée à une action et un contrôleur regroupe plusieurs actions au sein d'un même script) et le même codage par convention (introduit par Rails) que ZF. Et je te garantis qu'en terme de maintenance les gains sont tout aussi sensibles.

[rawsrc]

Si c'est réellement représentatif du code de configuration d'une application Web « basique » écrite avec ZF2, il est très clair qu'ils ont foiré le principe KISS et que je vais en rester à ZF1. Et je prédis à ZF2 le même avenir radieux qu'à PHP6...

C'est la mode des machins trucs bidules "full-stack" en PHP (qu'est ce je peux entendre ce mot en ce moment). Donc ça doit faire le café, griller les biscottes parfois même les beurrer. C'est clair que le principe KISS (Keep it simple and stupid) a été bel et bien enterré. Tu vois le virage de SF2, tu pleures.
C'est bien joli tous ces outils mais ils ont l'air d'avoir oublié quand même un principe de base : un développement c'est une unité homogène et fonctionnelle de codes sources. Et je n'ai jamais vu quelque part qu'on s'amusait à changer des pans entiers d'un programme du soir au matin, juste pour voir. Alors les patterns de la mort qui tue concernant les dépendances, les abstractions qui s'empilent juste pour être prêt à gérer tous les cas de figures et qui t'obligent à jouer les Experts (ou Derrick selon l'âge ) pour t'y retrouver, sont généralement inutiles pour 80% des fonctionnalités.

D'expérience, je peux vous assurer que les modifications substentielles de sites conduisent généralement à une réécriture pure et simple du code et la flexibilité tant mise en avant par ces outils n'est jamais utilisée.
Lors d'une présentation, j'ai même entendu : "si demain, vous décidez de changer d'ORM, rien de plus simple, yapuka..." mais le truc c'est que personne ne changera d'ORM sans bétonner à mort au préalable.
Et entre le temps où tout sera qualifié et prêt à être déployé, ton super outil (super robuste, ultra souple) et l'ORM auront évolué et qui me garantit que cela sera toujours compatible/fonctionnel.
Sans compter qu'il faudra remettre les mains dans le cambouis quand même. La magie en informatique ça n'existe pas. Y click Y click c'est du vent.
La boite vivra sur son vieil outil et décidera de le reprendre complètement après un certain temps. C'est comme ça, les évolutions progressives en informatique sont très rares. On avance par saut.

Donc retrouver ces outils en production me laisse pantois vu la surcouche que cela ajoute.

Les gens perdent en lucidité. Ils doivent penser que Copperfield est un vrai magicien.

[SurferIX]

Alors les patterns de la mort qui tue concernant les dépendances, les abstractions qui s'empilent juste pour être prêt à gérer tous les cas de figures et qui t'obligent à jouer les Experts pour t'y retrouver, sont généralement inutiles pour 80% des fonctionnalités.
....

La magie en informatique ça n'existe pas. Y click Y click c'est du vent.

Un énorme plus un pour tout ça !

[lemmoned]

Le temps de lire tous les commentaires, j'ai codé mon propre framework!

Je suis déjà dehors

[ypicot]

C'est la mode des machins trucs bidules "full-stack" en PHP (qu'est ce je peux entendre ce mot en ce moment). Donc ça doit faire le café, griller les biscottes parfois même les beurrer. C'est clair que le principe KISS (Keep it simple and stupid) a été bel et bien enterré. Tu vois le virage de SF2, tu pleures.

Là, je dois refaire un site web (heureusement assez simple) avec strictement aucun framework (impératif du client).
Je me re-re-re-tape toute la gestion des formulaires, la gestion des utilisateurs, la sécurité, etc à la main.

Ben je pleure.
Mais si je devais utiliser un mastodonte comme SF2, je crois que je pleurerai aussi.

Il n'y a pas un truc qui parle de "juste milieu", et surtout un autre qui parle de... ha ben oui, il est dans ma signature

Yvan

[FaridM]

Là, je dois refaire un site web (heureusement assez simple) avec strictement aucun framework (impératif du client).
Je me re-re-re-tape toute la gestion des formulaires, la gestion des utilisateurs, la sécurité, etc à la main.

Ben je pleure.
Mais si je devais utiliser un mastodonte comme SF2, je crois que je pleurerai aussi.

Il n'y a pas un truc qui parle de "juste milieu", et surtout un autre qui parle de... ha ben oui, il est dans ma signature

Yvan

Silex

[stealth35]

Silex

Pareil, j'en suis très content pour les petits site, ça simplifie beaucoup de chose

[Benjamin Delespierre]

Il n'y a pas un truc qui parle de "juste milieu", et surtout un autre qui parle de... ha ben oui, il est dans ma signature

Personnellement, j'ai développé Axiom en essayant d'être dans le "juste milieu" comme du dis

"In medio stad vertus."

[coolspot]

Je suis en apprentissage du framework CI pour depoussierer un peu mon site web qui est en from scratch avec un code et une base degeulasse datant de 2006.

[gtraxx]

J'utilise mes propres framework notamment magixcjquery dans la plupart des créations qui est également intégré dans mon propre CMS (Magix CMS).

Faut avouer créer son propre framework c'est très amusant, on multiplie son expérience, ses connaissances, les découvertes au sein même de conception.

Donc faire son petit framework c'est une excellente chose et non une perte de temps.

Les gros framework sont très intéressant, pour ma part j'en ai analysé pas mal et souvent la syntaxe utilisé ne me convenait pas.

C'est vrai que mon framework ne rivalise pas avec les plus grands mais il me satisfait, et à l'heure ou je vous parle un autre est sur le point de voir le jour en même temps qu'une grosse applis

Ma citation du jour
On comprend mieux sa logique que celle des autres, construire son propre chemin reflète toute la force, l’ingéniosité d'un développeur.

Il faut acquérir ses propres connaissances, ses propres expériences
avant d'emprunter le raccourci d'un autre.

[david_n]

Pour ma part, j'utilise Mouf, qui est un framework développé depuis 3 ans et que ma société vient de sortir en open-source.

Quels sont ses avantages?
- il s'agit d'un framework d'injection de dépendance
- avec une interface graphique pour éditer graphiquement son application (!)
- et plus de 100 modules (MVC, ORM, mail, cache, etc...) qui sont tous facultatifs (on peut donc le combiner avec un autre framework facilement (ou avec Drupal par exemple)
- stable (il est utilisé en production sur plusieurs sites)

Quels sont ses inconvénients?
- il demande une bonne connaissance de la programmation orienté objet (il s'inspire fortement des frameworks Java et ne s'adresse pas aux développeurs débutants)
- nous le sortons tout juste en open-source, donc il est pour l'instant supporté uniquement par TheCodingMachine
- mais... nous travaillons activement pour l'ouvrir à la communauté.

Alors n'hésitez pas à le tester, et même à nous rejoindre!

Le lien vers l'annonce de la release sur developpez.com:
http://www.developpez.net/forums/d11...ace-graphique/

Le lien vers le site du framework:
http://mouf-php.com


David
Lead developer
http://mouf-php.com

[Aurélien LEQUOY]

C'est la mode des machins trucs bidules "full-stack" en PHP (qu'est ce je peux entendre ce mot en ce moment). Donc ça doit faire le café, griller les biscottes parfois même les beurrer. C'est clair que le principe KISS (Keep it simple and stupid) a été bel et bien enterré. Tu vois le virage de SF2, tu pleures.
C'est bien joli tous ces outils mais ils ont l'air d'avoir oublié quand même un principe de base : un développement c'est une unité homogène et fonctionnelle de codes sources. Et je n'ai jamais vu quelque part qu'on s'amusait à changer des pans entiers d'un programme du soir au matin, juste pour voir. Alors les patterns de la mort qui tue concernant les dépendances, les abstractions qui s'empilent juste pour être prêt à gérer tous les cas de figures et qui t'obligent à jouer les Experts (ou Derrick selon l'âge ) pour t'y retrouver, sont généralement inutiles pour 80% des fonctionnalités.

D'expérience, je peux vous assurer que les modifications substentielles de sites conduisent généralement à une réécriture pure et simple du code et la flexibilité tant mise en avant par ces outils n'est jamais utilisée.
Lors d'une présentation, j'ai même entendu : "si demain, vous décidez de changer d'ORM, rien de plus simple, yapuka..." mais le truc c'est que personne ne changera d'ORM sans bétonner à mort au préalable.
Et entre le temps où tout sera qualifié et prêt à être déployé, ton super outil (super robuste, ultra souple) et l'ORM auront évolué et qui me garantit que cela sera toujours compatible/fonctionnel.
Sans compter qu'il faudra remettre les mains dans le cambouis quand même. La magie en informatique ça n'existe pas. Y click Y click c'est du vent.
La boite vivra sur son vieil outil et décidera de le reprendre complètement après un certain temps. C'est comme ça, les évolutions progressives en informatique sont très rares. On avance par saut.

Donc retrouver ces outils en production me laisse pantois vu la surcouche que cela ajoute.

Les gens perdent en lucidité. Ils doivent penser que Copperfield est un vrai magicien.

Je suis d'accord avec toi ainsi que SurferIX en Globalité. Je peux jamais m’empêcher d'ouvrir le Framwork pour voir comment c'est foutu et la plupart du temps je suis surpris par tout le superflu de code qu'on utilise pas (voir qui sert a rien, juste pour respecter un ligne de conduite imaginaire ?)

Pour moi un framework sert pour la plupart du temps à cadrer un développeur qui débute (ou pas?), afin qu'il respecte certaines normes et qu'il code pas n'importe où comme un gros gorret.

La couche d'abstraction SQL n'a pas lieu d'être je préfère maitrisé mes requêtes, quand tout est simple pas de problème mais quand ça se complique il faut limite apprendre un nouveau langage ce qui demande du temps et que le résultat des requêtes SQL généré n'est pas ce que l'on souhaite. Et qui va demander du d’exécution supplémentaire pour un bénéfice nul ? Enfin bref si vous avez un problème avec SQL ça peut-être une solution comme j'ai pu voir avec certains développeurs débutant.

Sur un projet parallèle au miens on devait utiliser CakePHP et il a fallu faire faire un migration de MySQL vers Oracle après 2 mois de commencement et bien figurer vous qu'il a fallu plus de 2 semaines et qu'on m'appelle à la rescousse pour trouver le problème, car l'équipe de départ n'a pas eu le réflexe de plonger dans le cœur du framework voir ce qui merder. (Le gros du problème était due à une erreur de config du serveur Oracle où utilisateur avait des vues sur le tablespace de mon projet (également sous Cake), alors évidement certaines tables étaient en conflit).

Un problème qui aurait du prendre 1 heur + la réécriture de 2 ~ 3 requêtes sans surcouche.


Un autre exemple concerne l'assimilation d'un fichier GROS excel à intégrer sur un autre framework réalisé de 2 manières différentes.

- La première avec un développeur pro framework de quelques années d'expérience.
- La seconde par moi même ("pur PHP" ? à non j'ai utilisé une lib pour parser le Excel en repectant le MVC du framework et le minimum syndicale)


Résultat :
- Première version : +2 de semaines avec ~30 secondes pour intégré le fichier. (abandonné)
- Deuxieme version : 1 semaine avec <1 secondes pour intégré le fichier


Tous ça pour dire le framework met un certain cadre au développeur (une certaine lourdeur aussi), un développeur qui produit du code pourrie from scratsh restera pourri avec un framework (peut-être un peu moins pour les partis qu'il utilise du framework).
L'avantage on a générale pas de problème à chercher ou à été pondu le code car l’arborescence est un minimum chiadé et il y en a pas partout dans tous les sens.


Mon point de vue :

J'ai commencer par développer mes propre classes (user/ formulaire / traitement d'image / multilingue / stats / ...), que je reprends et améliore a chaque nouveau projet qu'il soit sur un framework ou non.
En générale je trouve toujours moyen de m'affranchir des méthodes du framework pour les remplacer avec les miennes ce qui m'évite de longue heures de lecture de documentation quand on m'impose un nouveau framework.

qui peuvent être également utilisé avec du "pur PHP", ce qui réduit considérablement le temps de dév.

Maintenant j'utilise mon propre framework Synapse rebaptisé "Gliale" depuis que je l'ai intégralement réécrit (la structure) en 2010.


Quels sont les points forts de votre Framework favori, ses points faibles ?
Point forts :
- PHP strict
- Très rapide & très léger
- Adapté pour des très grosses bases de données. (marche avec une DB de 2.4 To sous MySQL, les conventions doivent être respectées)
- intégralement POO 5.3+
- intégration de javascript /jquery en natif
- développement par la notion de Concept
- gestion des droits utilisateurs en natif
- HTML 5 en natif pour certaines fonctions (depuis peu)

- contrôleur multi level ( 1 cache cache pour chaque level)
Pour faire simple chaque controlleur p-e appelé depuis l'url (si autorisé) ou depuis ajax ou un autre contrôleur avec uniquement l'exécution de la parti qui nous intéresse sans tout le reste autour avec historisation du contenu ajax et réécriture d'url. (dsl pas simple à expliquer simplement)

En clair vous avez un cadre dans une page (valable pour tous les cadres de cette même page et n'importe quelle level), ce cadre peut-être appelé depuis plusieurs autres pages différentes et même depuis ajax de tel manière à ce que si vous copier l'url pour un ami celui si verra exactement la même chose.
(tout l’intérêt du framework)

- gestion en natif multilingue (3 niveaux de cache) , avec la traduction automatique et intégrée pour les traducteurs (en cas de problème)
- UTF-8 en natif
- routage
- résolution et autoloading des classes
- intégration facile de plugins et d'outils tiers

Point faibles :
- 0 doc
- html olé olé
- certaines conventions utilisés assez complexe à comprendre (pour le multi level des contrôleurs)
- peux produire des url à ralonge avec l'ajax

Dans quels types de projet Web l’utilisez-vous ?
Tous

Est-il adapté comme premier Framework ?
Je pense que oui, la prise en main basique est plutôt facile, pour la modification de parti de contenu à la voler avec AJAX est plus ardue.


Je pense sortir ce framework en open source quand le site www.estrildidae.net sera mis en ligne utilisant toutes les fonctionnalités & possibilités du framework.

[GrandFather]

Pour moi un framework sert pour la plupart du temps à cadrer un développeur qui débute (ou pas?), afin qu'il respecte certaines normes et qu'il code pas n'importe où comme un gros gorret.

Mon avis est totalement opposé au tien, un framework ne sera exploité au mieux que par des développeurs un minimum aguerris, et qui ont déjà une expérience des problématiques de développement que ces frameworks sont censés aborder.

[Aurélien LEQUOY]

Mon avis est totalement opposé au tien, un framework ne sera exploité au mieux que par des développeurs un minimum aguerris, et qui ont déjà une expérience des problématiques de développement que ces frameworks sont censés aborder.

j'aurais du ajouter dans le contexte où le framework et les développeurs sont imposés :p

[SurferIX]

Mon avis est totalement opposé au tien, un framework ne sera exploité au mieux que par des développeurs un minimum aguerris, et qui ont déjà une expérience des problématiques de développement que ces frameworks sont censés aborder.

En fait si on regarde de près, le principe des framework c'est le DRY.
Ne jamais avoir à réécrire ce qu'on a déjà écrit.

Pour y arriver, on est obligé de "généraliser" et d'écrire quelque chose le plus générique possible.

Mais là où le bât blesse, c'est que lorsqu'on a terminé d'écrire quelque chose de générique, il faut systématiquement l'adapter à un nouveau contexte.

Et pour l'adapter à un nouveau contexte, on s'aperçoit que telle ou telle particularité pose problème, n'a jamais été imaginée, etc.

Et donc on en arrive à faire un boulot qui, quelque part, consiste à "gérer les exceptions dûes au contexte spécifique dans lequel on utilise le framework".

Ce qui fait qu'au final, on gagne peu de temps, parce que le temps de développement est aussi long, c'est juste le problème qui est déporté.

Par expérience, c'est ce que j'ai vu. Moi qui ne suis pas super fûté, je ne m'en suis aperçu qu'après pas mal de tests.

Mais quelqu'un de plus intelligent l'avait vu avant et a écrit un excellent article que je vous encourage à lire :

La loi des abstractions qui fuient, de Joel Spolsky

[Julien Alric]

C'est plus une observation empirique que d'une véritable loi, mais l'article est intéressant.

En général, une abstraction qui fui est une abstraction mal pensée ou non finalisé. On n'avait pas pensé à ça ? Il suffira souvent de modifier l'abstraction pour en tenir compte dans une prochaine version. Une fois qu'on a fait le tour de tous les uses cases pertinents les fuites rencontrés sont exceptionnelles et illustrent le plus souvent l'usage de mauvaises pratiques.

Heureusement qu'il n'est pas nécessaire de programmer en assembleur pour réaliser un site en PHP. Bien sur entre chaque couche il y a des pertes en terme de fonctionnalité mais ces pertes sont assumés car elles ne répondent pas aux besoins pour lesquels se destine ce langage (ou cette abstraction).

Le problème d'une abstraction du genre de celle d'un framework PHP, c'est qu'on veut une abstraction puissante, sans fuite, et ayant la même couverture fonctionnelle que le langage de base. Je partage assez l'avis de Rasmus quand il parle de wordpress et drupal comme des frameworks spécialisés, les seuls ayant du sens à ses yeux.

Le véritable intérêt de ce type d'abstraction, c'est la structuration du code qui en résulte, gage en général d'une bonne maintenabilité. Il ne faut pas pour autant oublier que cela à un cout en terme de performances. Je dis cela car j'ai souvenir d'une boite qui voulait généraliser l'usage d'un framework à tous ses développements... Ils ont finis par charger tout un framework pour des crons qui auraient pris en moyenne 20 lignes de PHP.

Pour moi, Zend et Symfony sont de superbes bibliothèques de composant bien écrits, pas une surcouche à PHP. A l'idée de framework, je préfère celle d'un bootstrap de code couplé à une mini stack MVC et pouvant interagir avec des composants externes.

[druith]

La seule raison qui m'aurait poussé à utiliser un framework usine à gaz tout en un, ça aurait été pour gérer la partie model de la construction MVC. C'est celle que je maîtrise (et qui m'amuse) le moins.

Mais depuis que j'ai découvert Idiorm et Paris, qui correspondent parfaitement à ce que je cherche (simple, qui ne fait pas le café et qui se contente de rendre les codes plus lisibles et sécurisés) je travaille avec la base d'un framework maison qui se résume globalement à une grosse classe "serveur php" qui gère les méthodes REST et le routing, à des bibliothèques extrêmement simplifiées pour aller plus vite (images, sessions, fichiers, cache etc.) que je modifie, améliore et enrichi pour chaque projet en fonction des besoins et d'un gestionnaire de réponses de type Fabrique qui me permet d'ajouter ou de supprimer à volonté les différents formats de sortie d'un projet.

Je connais chaque boucle de mon code et surtout je ne suis pas obligé de suivre les effets de mode qui changent tous les 2-3 ans pour chaque couches quand elles me semblent futiles (xml -> yaml -> json par exemple alors que dans 80% des cas un fichier config.php est plus simple à lire et à manipuler)

Ce qu'il faut avouer c'est qu'actuellement pour trouver du travail c'est quand même pas si mal d'avoir intégré une chapelle ("cherche développeur php5 et symfony" est devenu un pléonasme chez les RH)

[GrandFather]

A l'idée de framework, je préfère celle d'un bootstrap de code couplé à une mini stack MVC et pouvant interagir avec des composants externes.

En l'occurrence, Zend Framework semble plus correspondre à cette définition que Symphony, pour ce que j'ai pu constater.

[Julien Alric]

Zend a dès le début été construit en terme de composants indépendants, ce n'était pas le cas pour Symfony au départ, mais le framework a lui aussi évolué dans ce sens.

Zend, tout comme Symfony, ne correspondent pas à cette définition si on les utilise comme des framework full-stack. Leur implémentation du MVC est de part certains aspects trop lourde et inutile pour 95% des projets. Il en est de même pour les mécanismes élaborés d'injection de dépendance qui sont aujourd'hui mis en avant. PHP n'est pas Java.

Personnellement, j'ai développé mon propre boostrap de code, ma propre stack MVC, et j'ai rangé les composants Zend et Symfony parmi d'autres libs externes.
Ce qui ne m'empêche pas de promouvoir et d'utiliser Zend au taff et d'en apprécier toutes les qualités.

[Gugelhupf]

Pour ma je dirais Symfony2, car une fois avoir étudié un petit peu la documentation de différents framework PHP (et question quantité il y en a comme dans aucun autre langage) j'ai trouvé que c'était un bon framework assez complet.

Je partage l'avis de certains en ce qui concerne les framework "maison", à peser le pour et le contre je suis contre.
Alors certes cela permet à titre personnel de se développer en PHP, mais autrement c'est réinventer la roue selon moi... pourquoi ?

• Parce que les frameworks actuels sont pour la plupart tous libre, complet et conviennent à tout type de besoin.
• Parce que tu n'es pas productif dans ce que tu fais entre le développement et la mise à jour du framework maison et le projet que tu développes.
• Développer son propre framework au lieu de contribuer aux framework libres basés sur un langage libre c'est se renfermer sur soit même.
• Parce que les employeurs (les RH plutôt) se foutent complétement du framework toto ou du PHP, ce qu'ils veulent c'est du Zend ou Symfony.
• Parce que l'apprentissage du framework maison est contre productif en équipe, je m'explique : Ce n'est pas parce que je maitrise ce que j'ai produis que c'est le meilleur framework du monde, mon équipier qui connait Zend ou Symfony va prendre un certain temps pour la formation (perte de temps et d'argent).
• Quel est la qualité de la documentation des framework maison ?

S'il y a des gens aussi compétent et qu'on respecte pour leur savoir faire... Pourquoi ne pas contribuer au développement des puissants framework libres déjà existant ?
Pourquoi ne pas contribuer au développement du langage PHP ?

Encore un peu plus de connaissance et hop, après le framework tout le monde va se mettre créer son propre langage, son propre IDE, SGBD, et système d'exploitation (Microsoft l'a déjà fait vous me direz ).