Discussion :

[Invité]

J'ai utilisé Laravel et CodeIgniter dans le cadre de mes études. Et aujourd'hui je découvre Symfony 2 l'usine à gaz. Mais vu qu'il est très demandé sur le marché de l'emploi autant se spécialiser.

PHP forever for me !!

[jfadev]

Franchement, Symfony2 est le melleir framework PHP sans aucun doute.

[Mouke]

J'ai tout de même grandement l'impression de voir des gens expliquer qu'ils utilisent tel ou tel framework sans avoir la moindre idée du pourquoi... ça fait peur .

Personnellement je suis sur arrivé sur un projet qui avait déjà 1an et demi donc changer de framework n'est pas possible. Bien que ZF2 n'était pas le choix le plus pertinent il fait l'affaire.
Je doute être le seul dans cette situation.

[Bennette]

J'ai tout de même grandement l'impression de voir des gens expliquer qu'ils utilisent tel ou tel framework sans avoir la moindre idée du pourquoi... ça fait peur .

Complètement d'accord ... symfony, zf, la blague, c'est la "facilité" de dev au détriment des performances ... j'ai vraiment l'impression que la pluspart des devs sont formatés sur des frameworks et des libs (surement ceux qui ont payés des certifs ...) et ne savent rien faire sans car ils ne comprennent pas leur fonctionnement. Il ne faut pas oublier que PHP est déjà un framework du C donc plus on rajoute des couches et plus c'est lent. Le plus gros problème de lenteur viens du nombre de fichier à inclure, donc les gros framework avec des tonnes de fonctionnalité inutile permettant des devs "facile" pénalise grandement l'application aussi bien au niveau du temps d'accès que des ressources utilisées. Perso j'utilise Phalcon car j'ai un besoin de performance optimale mais sinon pour les hébergements mutualisés je me suis dev un framework très léger avec scrud à la volé et modèle MVC basique.

[llaffont]

J'utilise MKF car je le trouve assez simple et que je n'ai pas de gros projet WEB.
Je code souvent pour de l'applicatif Métier simple et peu couteux en temps de programmation.

Il s'agit toutefois d'un FrameWork qui mérite d'être connu car il est loin de l'usine à Gaz, il offre tout la sécurité nécessaire que l'on attends d'un FrameWork, il est Français, maintenu depuis de nombreuses années et surtout il est facile à prendre en main.
De mon point de vu et pour en avoir testé quelques autres, cela fait de lui un FrameWork idéale pour les débutants, les petits projets et les initiations scolaires.

[CoderInTheDark]

J’ai commencé PHP en 2000.
S’était que du travail à la main.
J’avais fait mon mini Framework, en PHP objet, pour créer les formulaires et leurs codes JavaScript automatiquement.
J’étais jeune et insouciant à cette époque.
J’en avais marre de réécrire le même code dans chaque pages.
Alors je suis content maintenant de faire du PHP avec un Framework.

Et surtout que maintenant je fais principalement du Java.
Mais on me demande aussi du PHP, utiliser un Framework me permet d’y revenir facilement.

Comment j’ai fait mon choix.
Lors d’un stage, on m’a demandé de choisir un Framework, pour le projet.
On a cherché à me pousser ver Zend.
Mais en 2012/2013 ce n’était pas une bonne idée, car on attendait une version stable de Zend 2.
De plus j’ai trouvé que Zend était trop fermé sur lui-même et monolithique.
Contrairement à Synfony, qui est plus ouvert, sur des projets externes (Doctrine, SwiftMailler,…).
En plus Synfony Pour moi qui voit rien c’est le pied, utiliser la console pour générer du code me facilite la vie contrairement aux outils graphiques.
En plus Doctrine me rappelle Hibernate.
Néanmoins je ne suis pas tout à fait convaincu par la réutilisabilité des bundles maisons et je les trouve parfois un peu lourd à manipuler.
J’ai adoré le moteur de template Twig.

Pour l’avenir, je souhaiterai apprendre un Framework PHP plus léger, pour les projets de plus petites tailles.
Je n’ai pas encore fait mon choix.
Je pense à Cake ou Larabelle ou même CodeIgniter
A propos peut-on attaquer la même base de données à la fois avec Hibernate et Doctrine ?
A grand coup d’annotation, par exemple, pour imposer le schéma à l’une des deux API ?

[imikado]

Pour l’avenir, je souhaiterai apprendre un Framework PHP plus léger, pour les projets de plus petites tailles.
Je n’ai pas encore fait mon choix.

Vous pouvez toujours "jeter un oeil" sur le mkf:

D'autres vidéos de présentation ici : http://mkframework.com/screencasts.html et oui c'est bien un framework et non un CMS

[u_ribellu]

La nouvelle version de CodeIgniter (V3) est vraiment TOP, pas aussi complexe que Symfony ou Zend mais beaucoup plus performante que Laravel ou CakePhp...

[SurferIX]

...La VM de développement Homestead préconfigurée. Idem, travaillant sous Windows je peux enfin bosser avec des extensions PHP dispo uniquement en Unix ! <3...

Pourquoi tu bosse pas tout simplement sur Unix ?

[SurferIX]

Franchement, Symfony2 est le melleir framework PHP sans aucun doute.

L'écriture est parfaitement en cohérence avec les tests que j'ai fait sur Symfony (deux sites pros montés de bout en bout, je sais donc de quoi je parle).
J'ai fait sur mon propre framework en deux heures ce qui m'avait pris une journée avec Symfony.
C'est vraiment essayer d'utiliser un bulldozer pour écraser une mouche, mais à tous les points de vue.
Le premier point le plus inacceptable est le mode déboguage.
Mon PC sous Windows a un indice de performance de 7.8. Windows 64 bits, 32 Go de RAM et disques SSD etc.
Lorsque je lance Php en mode débug pour essayer de faire du pas à pas sous PhpStorm, il mettait entre 12 et 28 s (chrono en mains) pour afficher une page.
Lorsque j'ai réussi à utiliser Symfony sur mon PC avec xdebug, j'ai la mâchoire qui est tombée par terre. La pile d'appel était de 17. Soit DIX SEPT appels de fonctions imbriquées les unes dans les autres.
Donc quelque part c'était normal qu'il mette entre 12 et 28 s (chrono en mains) pour afficher une page...
En tous les cas, DIX SEPT appels de fonctions imbriquées les unes dans les autres est absolument incompréhensible, ingérable et in-déboguable.
C'est pour ça que j'ai écrit un long article qui crache dessus Symfony, et les seuls adeptes de Symfony ne peuvent qu'être des gens qui n'ont pas connu d'autres bons frameworks, et qui, au même titre que les Mac addicts, n'admettrons jamais les défauts grossiers et inacceptables de leur joujou.
Sans parler des monstruosités où tu as des erreurs de l'espace qui t'empêchent totalement de savoir où est réellement ton erreur. Long article ici qui a sauvé des heures de boulot à plusieurs personnes... ou encore celle-ci...
Bref, j'ai fait pas mal d'articles par là sur Symfony qui montrent que j'ai bien appris le framework et que je sais de quoi je parle. Symfony est tellement complexe qu’il faut absolument avoir un débogueur intégré tel que xdebug et pouvoir faire du pas à pas dans un environnement tel que PhpStorm qui donne la possibilité de suivre tout, avec la pile d’appel. Rendez vous compte : pour développer un site Web simple, des frameworks comme symfony sont tellement complexes qu’il faut obligatoirement pouvoir faire du pas à pas. Ce sont des experts Symfony qui me l’ont expliqué. Sur le coup j’ai sincèrement (honnêtement, ce n’est pas ironique, c’est véridique) cru que c’était une blague. Php est tellement simple et fluide quand il est bien développé que je n’ai jamais eu à utiliser de débogueur pas à pas en plus de dix ans !
Pire : lorsque j'ai essayé d'utiliser FOSUserBundle et de le configurer, cela m'a pris une journée pour le faire tourner, car j'avais besoin de deux profils : un profil "prof" et un profil "étudiant". Cela m'aurait pris moins d'une heure à implémenter la chose dans mon "petit" framework de base. A tel point que j'ai posé la question ici sur stackoverflow : quel est l'intérêt de cet bouse immonde qu'est le FOSUserBundle ! Ah et après une journée de bataille, j'apprends qu'il ne gère pas la possibilité de faire deux formulaires d'enregistrements différents avec la possibilité de dérouter le hook d'enregistrement. Il faut installer un autre bundle en plus, le PUGXMultiUserBundle... Tenez vous bien, la réponse est on ne peut plus parlante : "la plupart du temps, tous les bundles sont trop étroitement liés à l'écosystème où ils ont été crées et c'est un problème qui rend le code illisible, et inexploitable".

Bref. J'ai fait mon propre système MVC fait maison et réécrit 4 fois, dont la 4ème = full rewrite pour mon mémoire d'ingénieur, qui est très rapide, très performant, MVC et permet d'utiliser Apache en mode Lamborghini (combien de vous savent qu'il a un moteur de base de données, Apache ?).
Malgré tout cela et un framework ultra optimisé, je vais aujourd'hui en Django / Python entre 2 et 10 fois plus vite qu'avec le reste. Le seul frein à ma rapidité c'est le Web, qui est un "work-in-progress" depuis plus de 20 ans sans jamais rien de stable et qui me fait perdre un temps fou (compatibilité et responsive êtes-vous là ?).

[Poulain]

Bonjour,

De mon cote, je tourne avec Symfony 2, car a l'époque a laquelle je cherchais un Framework, c'était celui -ci qui étai en vogue.
J'apprécie, c'est assez complet, même s'il faut un certain temps pour appréhender la bête. Tout le monde sait que ce n'est pas le Framework le plis rapide, mais avec un bon système de cache on peut normalement se rattraper en production.

J'ai utilise codeigniter aussi pour faire un petit projet, car symfony était beaucoup trop lourd pour ça, et a l'époque, je n'étais pas ai courant de l'existence de Silex, un micro-Framework de symfony : http://silex.sensiolabs.org/

Je n'ai pas encore essaye Silex, mais ça répond a la problématique de votre bazooka antimouche.

[SurferIX]

un micro-Framework de symfony : http://silex.sensiolabs.org/. Mais ça répond a la problématique de votre bazooka antimouche.

Silex = sous-ensemble de Symfony. Par là même, connaissant bien Symfony, je n'utiliserai pas Silex.
C'est Fabien Potencier lui même (créateur de Symfony) qui expliquait que le goulot d'étranglement de Php c'est l'accès aux fichiers.
En effet (et c'est logique), Php est obligé de voir si les fichiers ont été modifiés avant des les parser, afin de savoir s'il doit les recharger, ou pas.
A chaque chargement d'une seule page, Symfony fait plusieurs centaines de vérifications.

Voici le nombres de fichiers Php symfony sur mon site livrepizzas avec l'installation des bundles nécessaires :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
$ find . -type f | grep php$ | wc -l
5287

CINQ MILLE FICHIERS

Bref j'arrête, Symfony n'a que deux choses irréprochables : il est très bien documenté, et son code est très propre, donc il vend du rêve, il le vend même très bien.

[Ryuuzaki92]

J'utilise CodeIgniter qui convient parfaitement à mes besoins (perso).
Léger, simple, ne demande pas de création de tables, très peu de Config.

En voyant les usines à gaz telle que Symfony ou autre, j'ai pris peur :p

[YlianEstevez]

J'ai utilisé récemment le mkframework, un framework assez jeune mais très prometteur. J'ai aimé la simplicité de mise en oeuvre, la souplesse, la performance du builder, et la qualité du support, très réactif. Je conseille ce framework à la fois léger et performant.

[emilloz]

Bonjour,

Je connais Php depuis bien longtemps, et l'idée d'uin framework est bien séduisante.
Donc je suis mis à CakePHp 1.. (faut ouvrir plein de fichier mais c'est le prix à payer) puis Paf, le 2 est sorti... puis Symfony, grrr, pourquoi apprendre un Framework (perso je trouve lourd et empêche de se concentrer sur le sujet du dev.)
(pis exécuter des tonnes de procédure ca consomme du CPU...)

Donc, j'ai développé mon propre FrameWork , pas vraiment un frameWork , plutôt un outil de création de page et de mixage, avec un système pour accéder à la boite à outils, et un système de création de formulaire.
Ca vaut ce que ca vaut...sans prétentions.
(voir c'est un travail perso qui n'a pas grande vocation , pour ceux que ca intéresse voir sur milloz.net)

Bref, les FrameWork passent , Php reste.... super en client léger . (Dans la boite ou je suis , ils s’évertue de transformé les clients léger en client lourd, ca me fait marrer quand ca plante..)

[spoutbe]

je vais aujourd'hui en Django / Python entre 2 et 10 fois plus vite qu'avec le reste

+1, de CakePHP à Django, gain moyen de productivité constaté sur plusieurs projets: x3. Alors que je n'avais jamais tapé une seule ligne de Python auparavant.

[imikado]

Pour python django vs les autres frameworks php, pourriez vous développer illustrer par des exemples concrets (de gain de productivité) ?

[SurferIX]

Pour python django vs les autres frameworks php, pourriez vous développer illustrer par des exemples concrets (de gain de productivité) ?

Oui, rapidement. Premier gain de rapidité : les modèles. Exemple : fichiers models.py :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
class BaseModel(models.Model):
    date_creation = models.DateTimeField(auto_now_add=True)
    date_last_modif = models.DateTimeField(auto_now=True)

Hop ayé on a crée une table qui a des deux champs. Tu rajoute "abstract = True" et ta classe devient virtuelle = pas implémentée en base :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
class BaseModel(models.Model):
    date_creation = models.DateTimeField(auto_now_add=True)
    date_last_modif = models.DateTimeField(auto_now=True)
    date_v_debut = models.DateTimeField(default=datetime.now, editable=True)
    class Meta:
        abstract = True
        ordering = ['date_v_debut']

A partir de là tu dérive un modèle :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
class Personne(BaseModel):
    user = models.OneToOneField(User)
    champs_supplementaires = models.TextField(default=None)

Et hop ! Avec ces 11 lignes, tu as :
- un modèle de base dont toutes tes autres peuvent dériver via "class MaClasse(BaseModel):" (sisi c'est aussi simple que ça en Python)
- un modèle Personne = une table personne qui contient ces champs : date_creation, date_last_modif, date_v_debut, clé étrangère : user

Deuxième avantage qui m'a fait gagner un temps considérable : l'administration. Avec ces déclarations précédentes, voilà ce que tu as à faire pour avoir une interface d'admin complètement fonctionnelle : lancer deux lignes de commande : "manage.py [nomdetonappli] makemigrations". "manage.py [nomdetonappli] migrate". C'est pour qu'il applique les nouvelles tables en base. Sisi, rien de plus. Quand tu lance le serveur Python, hop, toute l'admin est entièrement générée. C'est pas du Symfony où il faut que tu vire tout, regénère tout, supprime le cache si jamais ton refresh en navigateur fonctionne pas, relance le serveur, enlève le mode débogue car trop lent, etc etc.

Troisième avantage : les utilisateurs. Django arrive avec une gestion parfaite des utilisateurs : Groups + permissions, et User qui est lié en relation n-n avec la table "Groups". C'est d'origine, t'as rien à faire ! J'ai pas à passer, comme avec Symfony, deux putains de jours sur le FOSUserBundle, puis sur le FPGUXMesBurnesUserBundle pour installer la gestion des droits, non non pas du tout, tout est déjà là, car toutes les applis web en ont besoin.

Ah j'oubliais : le fait de déclarer "user = models.OneToOneField(User)" il fait automatiquement un lien 1-1 avec la table User, et lorsque t'es dans l'interface d'admin, tout est prévu pour que tu puisse faire un lien avec le User via une combobox (vu que c'est un lien 1-1)

... je m'exprime peut-être mal, une image sera plus parlante : voilà une gestion 1-1 entre Personne et User (aucun code autre que ce qu'il y a au dessus, juré craché) :



Quatrième avantage : les vues sont basées sur des classes et ils ont préparé des vues "génériques" car tout le monde en a besoin ! La vue générique "liste" pour lister des éléments, et la vue générique "détail" pour le détail d'un élément en particulier.
Exemple concret :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
class IndexView(generic.ListView):
    template_name = 'applancement/index.html'
    context_object_name = 'liste_personnes'
 
    def get_queryset(self):
        """ Renvoyer toutes les personnes."""
        return Personne.objects.all()

Voilà. 6 lignes. Non non je ne blague pas, pas besoin d'en faire plus. Six lignes, lisibles, compréhensibles, faciles, et qui fonctionnent du premier coup. Et là tu as une vue totale prévue pour t'afficher la liste de toute la table des personnes.

Cinquième avantage : Symfony, avec son "Twig" dont il est si fier, a en réalité pompé totalement le système de templating de Django. Trois avantages : (1) il est super puissant (2) tu n'es pas du tout dépaysé si tu viens de Symfony ou que t'as fait du Smarty (3) comme il existe depuis des années, il a beaucoup d'avance sur Symfony.
Passons à l'exemple d'impléméntation du code juste au dessus :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
{% for personne in personnes %}
    {{ personne.nom }}
{% endfor %}

Et voilà. C'est fini. Ca tourne, c'est rapide, c'est quasiment instantané. Le boulot ne se compte plus en heures, mais en minutes.

Sixième avantage : et non des moindres : toute la documentation est en français, parfaitement suivie et mise à jour avec l'anglais. Rien de plus simple : t'as une URL avec "en" comme "english", tu remplace par "fr" et t'as toute la documentation en français. Et en français de très haut niveau (download = téléversement, etc) :
https://docs.djangoproject.com/en/1.8/ref/csrf/ -> https://docs.djangoproject.com/fr/1.8/ref/csrf/

Septième avantage : la traduction est non seulement ultra simple, utilise les outils classiques de Linux (pystorm vous aide à gérer simplement ça sur Windows), mais elle fonctionne et fonctionne de manière incroyablement simple.
Exemple : il te faut, dans tes vues inclure la ligne "i18n" en premier puis ajouter séparément les URLs que tu veux traduire comme ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
urlpatterns = [
    url(r'^i18n/', include('django.conf.urls.i18n')),
    # bla bla autre URLs "statiques",
]
urlpatterns += i18n_patterns(
    url(_(r'^produits/'),
        p_views.IndexView.as_view(), name='produits_index'),
)

La dernière configuration signifie "on peut taper "/produits" mais accepte la aussi, si tu la retrouves dans tes chaines de traduction, par exemple "/products" sera une URL valide et gérée automatiquement par Django, et enverra vers ta page "produits".
Et ça fonctionne. J'insiste par ce que j'ai halluciné de la facilité de mise en oeuvre. Allez si vous voulez continuer sur Symfony, je vous laisse lire la documentation... ah mais non il n'y en a pas, il faut installer... bah oui cliquez ici, c'est une question stackoverflow. Bonne chance pour installer le bundle fait par d'autres personnes, donc pas forcément maintenu, lire la documentation, essayer de comprendre comment ça fonctionne, créer les fichiers de configuration, relever toutes les chaines à traduire, etc.

Là, en plus, sur Pycharm, t'as toute la traduction ainsi :



Que demande le peuple ?

Huitième avantage : c'est lié à la syntaxe Python. Python peut non seulement avoir une longueur des arguments dynamiques, mais on peut utiliser le nom même des arguments : les arguments sont nommés, et si on veut les passer dans le désordre, tant qu'on les nomme, ça fonctionne. Django s'est servi de cela pour aider à faire des requêtes de manière très "parlante" : il faut séparer le champ concerné + type de filtre par deux tirets bas "__". Un exemple est plus parlant : personnes = Personne.objects.filter(nom__exact=monparam).all()
Et voilà tu aura toutes les personnes dont le nom vaut exactement "monparam". De là il te suffit juste de mettre ça dans les URLs comme cela : url(_(r'^personne/(?P<monparam>[a-zA-Z0-9-_]+)/$'), (oui parce qu'il peut appliquer les expressions régulières dans les URLs) et tu auras une URL parfaitement fonctionnelle.
Je te laisse imaginer qu'en quelques minutes, et en une vingtaine de lignes (ça n'est pas exagéré), tu peux réaliser une page totale qui affiche la liste de toutes les personnes dont le nom est en paramètre dans l'URL.

Neuvième avantage : la souplesse de l'interface admin. Tu ne veux afficher que certains champs quand on édite une table ? Tu ouvre le fichier admin.py et voici un exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
class ContenuInline(admin.TabularInline):
    model = Contenu
    extra = 0
    list_filter = ('titre', 'langue__active', LangueSimpleListFilter)
    fields = (('date_v_debut', 'date_v_fin'), 'resume', 'texte',
              ('image', 'image_tag'))
    readonly_fields = ('image_tag',)

Et ça fonctionne sans rien faire de plus. Je ne sais pas si tu réalise vraiment, mais en 8 lignes, tu dis ceci : "je veux dans l'interface d'admin, lorsque qu'on édite un item "Contenu", qu'il soit affiché en "inline" (= plus compacté), que pour le champ "titre", tu ne permette que de sélectionner parmi les titres des langues actives, que tu n'affiche que certains champs, que tu groupe deux champs ('date_v_debut', 'date_v_fin') sur une ligne et ('image', 'image_tag') sur une autre ligne (parce que ça de voir un champ par ligne ici), et que le champ image_tag ne soit pas modifiable, mais visible.

Sincèrement, prends du recul et essaie d'imaginer avec n'importe quel autre framework tout ce que tu dois faire pour ça. Sachant que, je le répète encore, tu n'as pas à générer l'interface d'admin, elle est entièrement auto-générée !

Je pourrais continuer encore des heures entières à expliquer plein de choses, comment j'ai fait un formulaire total d'inscription avec crsf et tout ça en moins d'une heure car tout est déjà implémenté (vu que tout le monde en a besoin sur les sites d'aujourd'hui), ou comment tu peux surcharger tout l'habillage de l'admin sans code (oui oui, sans code : il regarde si un dossier existe, si oui, il charge le CSS qu'il y a dedans au lieu d'appliquer le CSS par défaut, c'est donc vraiment sans une seule ligne de code supplémentaire) bref plus j'avance plus j'ai envie de faire plein de choses méchantes à Symfony, voire Php car je leur en veux à tous les deux de m'avoir fait perdre autant de temps, uniquement pour suivre "la mode", alors qu'il y a à côté des outils sublimes qui sont juste moins bien vendus. (On pourrait dire que je n'ai qu'à m'en vouloir à moi, mais pour manger, il faut bien suivre "la mode" et donc j'ai suivi la mode... je peux pas dire non plus "j'en veux au monde entier qui s'est tourné vers Php"...).

Bref quels sont les inconvénients que je trouve à Django depuis 4 mois que je pratique ? Un seul mais qui est pour une utilisation avancée : les URLs "à traduire" ne peuvent être mises que dans la configuration principale, et pas par "site web". (Oui parce que le système total de Django est prévu dès l'origine pour pouvoir faire plusieurs sites avec la même installation et les mêmes outils, bonne chance pour ceux qui sont sur Symfony et qui veulent partager leur repositories d'une application avec une autre ).

Autre inconvénient qui est une fonctionnalité qui montre que c'est fait pour des professionnels mais que je ne trouve pas pratique : la gestion des fichiers statiques fonctionne tant que t'es en mode debug = True, mais elle est désactivée et renvoie un 404 en production, parce qu'ils partent du principe que si tu fais du bon boulot, tu dois gérer tes fichiers statiques autrement que par le serveur Django lui même (ce qui est très "sain" comme principe, mais pas très "pratique" )

[Spartacusply]

J'utilisais CakePhP en version 2 et maintenant en version 3.

Après avoir testé et utilisé Laravel sur un projet pluôt conséquent, je trouve Cake meilleur à quasiment tous points de vue, le plus important étant sans doute le Routing, mais aussi l'internationalisation, l'ORM... j'en passe et des meilleurs.

J'ai aussi utilisé CodeIgniter récemment, mais il lui manque vraiment trop de composants pour être réellement intéressant, surtout étant donné qu'il vient juste d'être mis à jour (support des namespaces en 2048 ?...)

Symfony, déjà testé assez longuement mais je trouve que le gain de productivité apporté au projet n'est pas suffisant par rapport à la complexification supplémentaire par rapport à Cake si ce n'est l'apport de flexibilité de la notion de Bundles qui peuvent être "facilement" être exporté d'un projet à l'autre. Il faut avoué quand même que Doctrine est assez impressionant (mais complexe encore une fois, système d'annotation etc... bof bof)


Bref, CakePhP parce que "convention over configuration".

[imikado]

Premièrement, je n'utilise plus Symfony depuis la version 1, j'ai ensuite utilisé beaucoup Zend Framework de la 1.2, à la 1.12 en parallèle je continuais de faire évolue le mkf, je vais donc répondre ici avec celui-ci (si vous me permettez)

Oui, rapidement. Premier gain de rapidité : les modèles. Exemple : fichiers models.py :
(...)

Et hop ! Avec ces 11 lignes, tu as :
- un modèle de base dont toutes tes autres peuvent dériver via "class MaClasse(BaseModel):" (sisi c'est aussi simple que ça en Python)
- un modèle Personne = une table personne qui contient ces champs : date_creation, date_last_modif, date_v_debut, clé étrangère : user

Rien à dire, le mkf permet "juste" d'avoir un controle de cohérence pré enregistrement facilitant la création de formulaire (le champ se retrouve rempli avec les messages d'erreurs sur les bons champs : mail invalide, message trop long...)

Deuxième avantage qui m'a fait gagner un temps considérable : l'administration. Avec ces déclarations précédentes, voilà ce que tu as à faire pour avoir une interface d'admin complètement fonctionnelle : lancer deux lignes de commande : "manage.py [nomdetonappli] makemigrations". "manage.py [nomdetonappli] migrate". C'est pour qu'il applique les nouvelles tables en base. Sisi, rien de plus. Quand tu lance le serveur Python, hop, toute l'admin est entièrement générée. C'est pas du Symfony où il faut que tu vire tout, regénère tout, supprime le cache si jamais ton refresh en navigateur fonctionne pas, relance le serveur, enlève le mode débogue car trop lent, etc etc.

Le mkf, via son builder (interface web d'administration des projets) permet de générer en 3 clics un module CRUD (create, read, update, delete) "sécurisé" (xsf,xsrf, sql injection et null byte)

Troisième avantage : les utilisateurs. Django arrive avec une gestion parfaite des utilisateurs : Groups + permissions, et User qui est lié en relation n-n avec la table "Groups". C'est d'origine, t'as rien à faire ! J'ai pas à passer, comme avec Symfony, deux putains de jours sur le FOSUserBundle, puis sur le FPGUXMesBurnesUserBundle pour installer la gestion des droits, non non pas du tout, tout est déjà là, car toutes les applis web en ont besoin.

Le builder, permet en 3 clics de générer un module d'authentification mono ou multi-groupes, avec page d'administration des utilisateurs, et des permissions.
De plus, la barre de debug, permet de verifier les permissions vérifiées sur une page

Quatrième avantage : les vues sont basées sur des classes et ils ont préparé des vues "génériques" car tout le monde en a besoin ! La vue générique "liste" pour lister des éléments, et la vue générique "détail" pour le détail d'un élément en particulier.
Exemple concret :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
class IndexView(generic.ListView):
    template_name = 'applancement/index.html'
    context_object_name = 'liste_personnes'
 
    def get_queryset(self):
        """ Renvoyer toutes les personnes."""
        return Personne.objects.all()

Voilà. 6 lignes. Non non je ne blague pas, pas besoin d'en faire plus. Six lignes, lisibles, compréhensibles, faciles, et qui fonctionnent du premier coup. Et là tu as une vue totale prévue pour t'afficher la liste de toute la table des personnes.

Déjà répondu: génération de CRUD en 3 clics, suffit après d'aller modifier le code généré

Sixième avantage : et non des moindres : toute la documentation est en français, parfaitement suivie et mise à jour avec l'anglais. Rien de plus simple : t'as une URL avec "en" comme "english", tu remplace par "fr" et t'as toute la documentation en français. Et en français de très haut niveau (download = téléversement, etc) :
https://docs.djangoproject.com/en/1.8/ref/csrf/ -> https://docs.djangoproject.com/fr/1.8/ref/csrf/

Documentation français(primaire) et anglais, tutoriaux écrit et vidéos (une vingtaine), et le générateur web sera multilingue dans le mois (traduction en cours de finalisation)

Septième avantage : la traduction est non seulement ultra simple, utilise les outils classiques de Linux (pystorm vous aide à gérer simplement ça sur Windows), mais elle fonctionne et fonctionne de manière incroyablement simple.
Exemple : il te faut, dans tes vues inclure la ligne "i18n" en premier puis ajouter séparément les URLs que tu veux traduire comme ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
urlpatterns = [
    url(r'^i18n/', include('django.conf.urls.i18n')),
    # bla bla autre URLs "statiques",
]
urlpatterns += i18n_patterns(
    url(_(r'^produits/'),
        p_views.IndexView.as_view(), name='produits_index'),
)

Le builder, possède un lien "explorer un projet" qui permet non seulement de "naviguer" dans son projet, mais en plus de la coloration syntaxique, chaque appel à un élément du framework est un lien vers la documentation associée

Neuvième avantage : la souplesse de l'interface admin. Tu ne veux afficher que certains champs quand on édite une table ? Tu ouvre le fichier admin.py et voici un exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
class ContenuInline(admin.TabularInline):
    model = Contenu
    extra = 0
    list_filter = ('titre', 'langue__active', LangueSimpleListFilter)
    fields = (('date_v_debut', 'date_v_fin'), 'resume', 'texte',
              ('image', 'image_tag'))
    readonly_fields = ('image_tag',)

Idem réponse plus haut: le builder propose de générer son CRUD avec plusieurs options, dont celui d'afficher ou non tel ou tel champs...

On peut même choisir de générer un CRUD avec la bibliothèque Guriddo

Je pourrais continuer encore des heures entières à expliquer plein de choses, comment j'ai fait un formulaire total d'inscription avec crsf et tout ça en moins d'une heure car tout est déjà implémenté (vu que tout le monde en a besoin sur les sites d'aujourd'hui),

Il y a une vidéo pour créer son propre "twitter" like en une heure avec le mkf; et encore ce tutoriel date un peu, des fonctions ont été ajoutées entre temps
Le tuto dvp "écrit", pour la vidéo, cherchez "MkFramework microblogging" sur youtube
http://imikado.developpez.com/tutori...microblogging/



Merci d'avoir pris le temps d'exposer ces avantages de django : pour les paramètres "nommés" c'est en effet très interessant (ça fait un peu penser aux placeholders en pdo)

De plus, prochainement, le mkf accueillera un market permettant à la communauté d'écrire et proposer sur ce store des modules de générations, modules et plugins pour enrichir l'expérience