Discussion :

[Spartacusply]

@SurferIX

Marrant, y a 30 secondes j'écrivais ma réponse à la question de base, entre temps tu rédiges ton argumentaire pour le couple Python/Django.

Le truc (et c'est là que c'est terrible), c'est que Cake fait mieux (au pire aussi bien) sur quasiment tous les points que tu viens d'évoquer.

Si je les reprends un par un :

L'avantage des modèles extrèmement rapide à écrire : Cake fait la même chose sauf... que tu n'as même pas à prendre la peine d'écrire une seule ligne. En effet, Cake se sert directement des types en base pour déterminer le type des attributs dans classes : Un datetime, sera un objet de type Time (qui hérite de DateTime avec en plus la gestion de l'i18n), un tinyint sur un seul caractère (sous mysql) sera un booléen, un varchar, un champ text etc...
En gros, tu créer ta table "personnes" en base et tu pourras te servir d'un entité "Personne" dans ton code avec tous les attributs prédéterminés par leur type en base sans que tu n'ai à écrire la moindre ligne de code et donc de créer la moindre classe.
Mieux encore, il détecte les clefs étrangères en base en fonction de leur écriture : si ta table "articles" possède un champ "journal_id", Cake comprend que chaque article est lié à un et un seul journal qui sera représenté par une classe "Journal" dans ton code.

Le deuxième avantage, gestion des migrations : là comme tu l'auras compris je pense, Cake fonctionne uniquement dans l'autre sens, c'est à dire, je créé la base et ensuite je génère le code. C'est idem, en deux lignes de commandes on génère l'ensemble des modèles de l'application (et un CRUD entier sur toutes les cmême si on veut).

Le troisième avantage, la gestion des utilisateurs : très simple aussi dans Cake, quelques lignes suffisent, de base possibilité d'utiliser Basic et Digest en plus du classique formulaire d'authentification.

Quatrième avantage, les vues génériques : ça marche un peu différement sous Cake mais tout aussi bien avec toujours aussi peu de ligne que dans ce cas là. Il faudrait passer ce qu'on appelle un helper qui sert à 'générer' des bouts de vues.

Cinquième avantage, le templating : sous Cake, c'est du templating php à la base comme ça au moins chacun fait ce qu'il veut et c'est pas plus mal (on peut intégrer twig très facilement), perso je préfère rester sur du templating php, surtout depuis que l' balise "<?=" est toujours dispo maintenant et ne dépend plus de l'environnement.

Sixième point, doc en français : idem, à quelques rares exceptions près.

Septième point l'internationalisation : point fort de Cake pour le coup, utilise la méthode gettext et intl, extension native de php lui-même (et ça, c'est quand même vachement bien). Voici un exemple de fichier de routing commenté qui gère l'internationalisation des urls :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
<?php
Router::defaultRouteClass('Route');
 
$scopes = function ($routes) {
	/** Parse les extensions json, c-a-d, dans une url qui se termine par .json, un résultat json sera renvoyé (et non un fichier html) */
    $routes->extensions(['json']);
	/** Je dirige vers ma page d'accueil **/
    $routes->connect('/', ['controller' => 'Articles', 'action' => 'index']);
	/** Gestion de toutes les pages statiques, qui ne passent pas par un controlleur **/
    $routes->connect('/pages/*', ['controller' => 'Pages', 'action' => 'display']);
	/** Indique que je veux utiliser les ""dashed_routes"" **/
    $routes->fallbacks('DashedRoute');
};
 
/** Gestion du multilingue**//
$languages = Configure::read('Language.list');
$languageDefault = Configure::read('Language.default');
unset($languages[$languageDefault]);
 
/** On indique que si c'est la langue par défaut, elle n'apparait pas dans l'url **/
Router::scope("/", ['lang' => $languageDefault], $scopes);
 
/** Pour chaque langue (sauf celle par défaut), j'indique que le langue sera indiquée au début de l'url comme telle : /es, /en...  **/
foreach ($languages as $lang => $intl) {
    Router::scope("/$lang", ['lang' => $lang], $scopes);
}
 
/** Le parmètre de la langue doit être garder lors de la création des liens **/
Router::addUrlFilter(function ($params, $request) {
    if (empty($params['lang'])) {
        $params['lang'] = $request->param('lang');
    }
    return $params;
});
 
Plugin::routes();

L'internationalisation de champs en bdd est aussi prévue et très facile à exploiter.

8ème point, les arguments dynamiques : pas trop compris, ça m'a l'air très complexe au lieu d'être simple. Pourquoi ne pas passer par la query string ? TU peux donner un exemple d'url qui utilise les arguments dynamiques, je visualise pas trop ?

9ème point, l'interface admin : Comme je l'ai déjà dit, Cake permet de générer entièrement un CRUD en fonction de la base de données. Ce qu'il est recommandé de faire c'est de générer les modèles à partie de la base, de repasser sur ces modèles pour corriger les éventuelles modifications, rajouter ce qui ne peut être deviner, puis générer ensuite les controlleurs et vues à partir de ces modèles.

[TiranusKBX]

@SurferIX & @imikado
Si vous voulez lancer un débats entre vous deux créer donc une discution pour, la ça commence à dériver pas mal du sujet
ce serait dommage de tout gâcher

[SurferIX]

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)...

Globalement cela semble un bon framework. Après il est lié à Php : syntaxe longue, permissive, pas de possibilité d'héritage multiple, aucune documentation interne (je dis cela car Python, en natif, a la possibilité de documenter les classes et fonctions : il suffit de mettre le bon commentaire au bon endroit), la possibilité aisée de faire des horreurs impossible à gérer en maintenance (là je parle de vécu où des développeurs en sont presque venus aux mains à cause de la pression mise par les clients et le fait que Php permettait de faire autant d'immondices), etc. Python gère en natif les entiers de longueur... illimitée : oui on peut faire 2^654654 si la mémoire du PC permet de gérer cela, il gère les nombres complexes en natif, il est plus concis, donc par essence même plus lisible, bref, même s'il existe des frameworks Php plus rapides ou plus pratiques que les "gros", rien ne me refera revenir faire du Php, encore moins avec Symfony, à moins que je n'ai plus le choix en terme de gagner de l'alimentaire. Python est mieux que Php, sur tous les niveaux, et tous les points, sans aucune exception (je suis expert Php depuis plus de 3 ans, je sais de quoi je parle... malheureusement ).

Donc bravo pour le mkframework, et merci développez, car via ma dernière réponse, j'ai eu énormément de retours positifs et de contacts, pour lesquels je vais "vendre" du Python, dans le but de faire de notre planète un monde meilleur.

@SurferIX & @imikado
Si vous voulez lancer un débats entre vous deux créer donc une discution pour, la ça commence à dériver pas mal du sujet ce serait dommage de tout gâcher

Gâcher quoi ? Les réponses sont toutes constructives et expliquent dans le détail des choses sur des frameworks. C'est l'une des discussions les plus constructives que j'aie eues depuis longtemps sur développez.

[papajoker]

Gâcher quoi ? Les réponses sont toutes constructives et expliquent dans le détail des choses sur des frameworks. C'est l'une des discussions les plus constructives que j'aie eues depuis longtemps sur développez.

MAIS la question est : Quel(s) framework(s) PHP utilisez-vous en 2015
ici tu nous vend un autre langage bravo le HS. Ouvre donc un fil quel langage/framawork pour faire un site web pour que les dev ruby, java,#... puissent participer à ta discussion constructive.

[SurferIX]

MAIS la question est : Quel(s) framework(s) PHP utilisez-vous en 2015
ici tu nous vend un autre langage bravo le HS. Ouvre donc un fil quel langage/framawork pour faire un site web pour que les dev ruby, java,#... puissent participer à ta discussion constructive.

Si toutes les dérives de développez dans les forums étaient aussi constructives, crois moi que j'en lirais beaucoup moins en diagonale avant de les refermer en pensant "temps perdu".
Cela dit tu as raison : je n'essaierai plus de partager mon savoir et les avantages et inconvénients d'autres frameworks, c'est mon dernier post ici.
Je te laisse en compagnie de ceux qui veulent juste dire "moi j'utiliste tel ou tel framework Php".

Le truc (et c'est là que c'est terrible), c'est que Cake fait mieux (au pire aussi bien) sur quasiment tous les points que tu viens d'évoquer.

(troll)Impossible par sa fondation même : Cake est en Php. (/troll)

L'avantage des modèles extrèmement rapide à écrire : Cake fait la même chose sauf... que tu n'as même pas à prendre la peine d'écrire une seule ligne. En effet, Cake se sert directement des types en base pour déterminer le type des attributs dans classes : Un datetime, sera un objet de type Time (qui hérite de DateTime avec en plus la gestion de l'i18n), un tinyint sur un seul caractère (sous mysql) sera un booléen, un varchar, un champ text etc...
En gros, tu créer ta table "personnes" en base et tu pourras te servir d'un entité "Personne" dans ton code avec tous les attributs prédéterminés par leur type en base sans que tu n'ai à écrire la moindre ligne de code et donc de créer la moindre classe.
Mieux encore, il détecte les clefs étrangères en base en fonction de leur écriture : si ta table "articles" possède un champ "journal_id", Cake comprend que chaque article est lié à un et un seul journal qui sera représenté par une classe "Journal" dans ton code.

WTF ? Tu veux dire que si un jour tu veux passer en NoSQL tu ne pourras jamais car il se base sur les types de champs que lui renvoie la BD ??? C'est une blague ?

Le deuxième avantage, gestion des migrations : là comme tu l'auras compris je pense, Cake fonctionne uniquement dans l'autre sens, c'est à dire, je créé la base et ensuite je génère le code. C'est idem, en deux lignes de commandes on génère l'ensemble des modèles de l'application (et un CRUD entier sur toutes les cmême si on veut).

Je ne l'ai pas dit mais Django est tellement bien fait que je n'ai jamais eu de CRUD à faire, justement. Alors que sur tous les MVC Php évoqués ci-avant, oui.

Le troisième avantage, la gestion des utilisateurs : très simple aussi dans Cake, quelques lignes suffisent, de base possibilité d'utiliser Basic et Digest en plus du classique formulaire d'authentification.

Quelque lignes suffisent ? Aucune avec Django car c'est en natif. Et pour la sécurité tout est aussi implémenté en natif.

Quatrième avantage, les vues génériques : ça marche un peu différemment sous Cake mais tout aussi bien avec toujours aussi peu de ligne que dans ce cas là. Il faudrait passer ce qu'on appelle un helper qui sert à 'générer' des bouts de vues.

Même chose : que tu le veuilles ou pas, tu dois encore passer par des contournement, utiliser des trucs, avec une courbe d'apprentissage.

Cinquième avantage, le templating : sous Cake, c'est du templating php à la base comme ça au moins chacun fait ce qu'il veut et c'est pas plus mal (on peut intégrer twig très facilement), perso je préfère rester sur du templating php, surtout depuis que l' balise "<?=" est toujours dispo maintenant et ne dépend plus de l'environnement.

Bien sûr !!!!!!!!!!!!! Le jour où, comme moi, tu te retrouveras à demander à toute une équipe de graphistes de travailler sur un dossier des templates que tu voudras partager - ce que j'ai du faire, tu changeras totalement ton fusil d'épaule. Templating php = pour développeurs, templating Twig / Smarty / Django = pour graphistes.

[QUOTE=Spartacusply;8413794]Sixième point, doc en français : idem, à quelques rares exceptions près.
"quelques rares exceptions près" : c'est tout le problème.

Septième point l'internationalisation : point fort de Cake pour le coup

Impossible. Juste absolument impossible de par Php, qui ne gère pas nativement, correctement l'utf8.
Lire ici sur la doc même de Php. Je cite "Avertissement
En interne, les chaînes PHP sont des tableaux d'octets.". Ce qui donne lieu à des strlen() et mb_strlen() voire l'immondice qu'on retrouve dans php.ini : default_charset string je vous laisse lire la doc qui vérifie cela : toutes les fonctions qui "surchargent" les fonctions chaines.
Tout est dit. En python, soit sur la 2 tu précise par une lettre quelle est ta chaine : "u" pour unicode, "r" pour "raw", etc du style a=u"Olivié" soit sur Python 3 tout est en utf8 d'origine et tu précise uniquement si tu ne veux pas que ça soit de l'utf8, mais python gère en natif tous les encodages, je cite "Python 2.7 comes with roughly 100 different encodings". De base. Merci au revoir Php.

utilise la méthode gettext et intl, extension native de php lui-même (et ça, c'est quand même vachement bien).

Oh que non, voire mon "rant" juste au dessus.

Voici un exemple de fichier de routing commenté qui gère l'internationalisation des urls :

Tu trouve que 8 lignes claires et efficaces, qui font la même chose que 36 lignes, qui nécessitent un commentaire d'explication c'est plus maintenable ? Vraiment ? Honnêtement ?

8ème point, les arguments dynamiques : pas trop compris, ça m'a l'air très complexe au lieu d'être simple. Pourquoi ne pas passer par la query string ? TU peux donner un exemple d'url qui utilise les arguments dynamiques, je visualise pas trop ?

Ca t'évite, justement, de faire des requêtes, et ça te permet d'utiliser les modèles, et c'est très parlant. Voici mon code copier coller tel quel : il sélectionne toutes les descriptions d'un produit qui fait partie de la vente dont le nom est dans le slug = dans l'URL:

Code :

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

1
2
3
4
5
6
        context['produit_description'] =
            Vente.objects.get(
                descriptions__slug__exact=slug
            ).produit.descriptions.get(
                langue__locale__exact=common.locale
            )

Tu trouve ça plus simple de faire ca :
--------------

Code :

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

1
2
3
4
5
6
SELECT descriptions
FROM produit p
WHERE id_langue = common.locale
JOIN produit_vente pv
ON pv.id_produit=p.id
AND pv.id_vente IN (SELECT id_vente FROM vente_description WHERE id_description IN (SELECT * FROM description WHERE slug= slug))

--------------
? Honnêtement ?

9ème point, l'interface admin : Comme je l'ai déjà dit, Cake permet de générer entièrement un CRUD en fonction de la base de données. Ce qu'il est recommandé de faire c'est de générer les modèles à partie de la base, de repasser sur ces modèles pour corriger les éventuelles modifications, rajouter ce qui ne peut être deviner, puis générer ensuite les controlleurs et vues à partir de ces modèles.

Excellent ! Rien que de lire ce qui est "conseillé" de faire détruit totalement Cake : en Django, tu rien à faire de tout ça. J'ai bien relu, et oui, je n'exagère pas : tu dois préciser uniquement ce que tu veux afficher et comment. T'as vu tout ce que tu dois faire juste pour faire une belle interface d'admin ?

Bref j'arrête d'essayer de vendre du Django, et surtout un grand merci pour toutes ces précisions qui seront utiles à ceux qui veulent essayer CakePhp... et pour toutes ces précisions qui seront utiles à ceux qui veulent essayer Django aussi

[Spartacusply]

WTF ? Tu veux dire que si un jour tu veux passer en NoSQL tu ne pourras jamais car il se base sur les types de champs que lui renvoie la BD ??? C'est une blague ?

Lol, bien sûr je ne l'ai pas indiqué mais toutes les conventions par défaut de Cake peuvent-être précisées, ajoutées, réécrites. Juste dans le cas de NoSQL, CakePhp ne pourra évidemment rien deviner de lui-même, il faudra obligatoirement lui préciser (pas trop le choix en même temps).

Bien sûr !!!!!!!!!!!!! Le jour où, comme moi, tu te retrouveras à demander à toute une équipe de graphistes de travailler sur un dossier des templates que tu voudras partager - ce que j'ai du faire, tu changeras totalement ton fusil d'épaule. Templating php = pour développeurs, templating Twig / Smarty / Django = pour graphistes.

C'est vrai, je n'ai pas grand chose à répondre à ceci puisque c'est toujours moi qui ai fait l'intégration des templates html à la fin.

Septième point l'internationalisation : point fort de Cake pour le coup

Impossible. Juste absolument impossible de par Php, qui ne gère pas nativement, correctement l'utf8.
Lire ici sur la doc même de Php. Je cite "Avertissement
En interne, les chaînes PHP sont des tableaux d'octets.". Ce qui donne lieu à des strlen() et mb_strlen() voire l'immondice qu'on retrouve dans php.ini : default_charset string je vous laisse lire la doc qui vérifie cela : toutes les fonctions qui "surchargent" les fonctions chaines.
Tout est dit. En python, soit sur la 2 tu précise par une lettre quelle est ta chaine : "u" pour unicode, "r" pour "raw", etc du style a=u"Olivié" soit sur Python 3 tout est en utf8 d'origine et tu précise uniquement si tu ne veux pas que ça soit de l'utf8, mais python gère en natif tous les encodages, je cite "Python 2.7 comes with roughly 100 different encodings". De base. Merci au revoir Php.

utilise la méthode gettext et intl, extension native de php lui-même (et ça, c'est quand même vachement bien).

Oh que non, voire mon "rant" juste au dessus.

Non mais ça d'accord, que PHP ne supporte pas l'UTF-8, c'est chiant. Mais y au d'autres trucs que l'encodage en interne des caractères à gérer quand on internationalise un site.
Déjà l'internationalisation ne se cantonne pas au texte lui-même : ca concerne aussi la monnaie, les dates... Et c'est surtout, comment on organise ça en interne, comment on stocke les infos ? Comment on limite l'impact sur les performances ? Quelle méthode va être utilisée ? Donc, dans ce cadre là, l'utilisation de la méthode gettext et de intl sont des très bonnes nouvelles car elle fonctionnent bien, elles sont natives et ont fait leurs preuves. Pas de surcouches débiles qui réécrivent foireusement des principes qui marchent correctement. Comment c'est visible dans l'url ? Et niveau référencement ? Pour le coup, je te l'assure Cake est vachement bien foutu à ce niveau là (mais ne permet pas évidemment d'outrepasser les limites de PHP dans ce douloureux sujet je te le concède).

Tu trouve que 8 lignes claires et efficaces, qui font la même chose que 36 lignes, qui nécessitent un commentaire d'explication c'est plus maintenable ? Vraiment ? Honnêtement ?

Lol, j'ai mis l'entièreté du fichier de routing, pas uniquement la part qui concerne l'internationalisation. Je vois aussi un include et des "blabla" avec des adresses statiques (y'a pas d'adresses statiques dans Cake...). Les commentaires ne sont là que pour expliquer justement ici sur le forum, dans le projet, ils sont totalement inutiles.

Tu trouve ça plus simple de faire ca :
--------------
SELECT descriptions
FROM produit p
WHERE id_langue = common.locale
JOIN produit_vente pv
ON pv.id_produit=p.id
AND pv.id_vente IN (SELECT id_vente FROM vente_description WHERE id_description IN (SELECT * FROM description WHERE slug= slug))
--------------
? Honnêtement ?

C'est un query builder en fait ? Comme dans tout bon ORM qui se respecte ? Non parce que, t'inquiète pas, le SQL je l'écris pas non plus ^^

Excellent ! Rien que de lire ce qui est "conseillé" de faire détruit totalement Cake : en Django, tu rien à faire de tout ça. J'ai bien relu, et oui, je n'exagère pas : tu dois préciser uniquement ce que tu veux afficher et comment. T'as vu tout ce que tu dois faire juste pour faire une belle interface d'admin ?

Ben... oui. Trois lignes de commande, avec un arrêt après la première qui, si ta base respecte les conventions Cake, devrait vraiment être expéditif.

[Sergeobee]

Si vous maîtrisez un framework ou que vous travaillez dans un projet où il est utilisé, tant mieux.

Perso, que ce soit avec Zend, Symfony ou un autre, on se retrouve à passer plus de temps à apprendre la logique du framework qu'à véritablement coder.

Comme plusieurs ici, j'ai commencé à développer mon framework perso depuis 2009 en commentant suffisamment pour me retrouver. A chaque nouvelle avancée PHP, j'intègre dans des librairies que j'appelle dans mon bootstrapp.

[ryan0108]

Faut bien commencer un jour !

Je débute globalement en php, petite experience sur drupal/wordpress, et depuis peu je me suis mis à codeigniter après de longues recherche pour trouver ce qui me conviendrait le mieux. Pour l'instant, je ne peux qu'être satisfait, bien que mes besoins soient relativement simples. J'ai commencé avec Bonfire, histoire de gagner un peu de temps, mais plus j'avance, et plus je fais moi même. J'ai choisis CI notamment pour sa simplicité et rapidité d'apprentissage vanté sur les comparateurs et forums, et pour l'instant, je ne suis pas déçu

[BeanzMaster]

J'utilise un framework perso que je développe depuis quelques années. Ca me permet de mieux coller et d'être plus réactif aux demandes de mes clients. De plus mon framework as un système de template totalement séparé du code PHP. Je peux à loisirs choisir le framework CSS et JS que je veux sans contraintes et me permet de placer mes éléments réellement comme je l'entend et leur données le dynamisme que je souhaites. Cela ma permis d'optimiser mon temps de travail au niveau de l'intégration. Je peux même déléguer cette partie à un webmaster ne connaissant rien au PHP. Et lorsque le cas se présente je peux directement inclure mes fonctions d'édition de données dynamiquement sans avoir recours à un backend lourd à gérer. Je gagne du temps lorsque je doit former le client.

[webtb]

C'est fait maison. Ce n'est pas un vrai framework, mais plutôt une série de class helpers. Je n'ai pas de vrai MVC.
D'ailleurs je le ferais dans mes prochains dev. Cependant je n'utiliserais pas les framework du genre de ZendFramework. J'ai eu la nécessite de travailler avec pour développer un outils de gestion commerciale, l'horreur !
Lors du développement, les plus grandes parties des questions portaient sur comment le faire avec le framework sans trop perdre de temps, en performance, etc.

[Sodium]

Après, le problème avec un Framework fait maison, c'est que le jour où l'on se retrouve à travailler avec d'autres développeurs, ils vont réclamer une doc.
Or, avec une doc, plus question de faire évoluer le Core au gré des envies, et l'on perd donc beaucoup en liberté.
Il est rare que d'un projet à l'autre, je n'apporte pas d'améliorations significatives à un ou plusieurs composants, en tentant si possible de les appliquer aux projets antérieurs.

[imikado]

Pour vos projets "maison" pensez à les mettre opensource, cela permet:-

• d'avoir un/des avis critiques
• des axes d'améliorations
• des remontés de bugs
• des remontés de failles de sécurité

Perso, le mkframework, possède depuis peu un market qui accueillera dans les prochaines semaines les productions de la communauté

La communauté ça n'a pas de prix

[yonisolo]

J'utilise un framework perso, cependant il est construit à partir d'élément existant pour la majeur parti. J'ai le côté gestion des contrôleurs de ZF mais j'adore le moteur de template de symfony et la gestion de mes entités avec doctrine, mon framework est un mix de tout ça...
merci à @SurferIX et @Spartacusply pour leur débat passionné et constructif même si je suis d'accord sur la plupart des points de SurferIX, prendre django en comparaison est HS.
je pense que la question est en fait un sondage sur l'effet de mode du moment, et que chaque éditeurs se tirent vers le haut quand un concurrent sort un truc cool...
Merci @imikado pour son MKF.

[boutmos]

J'ai utilisé un framework maison pour une grosse administration du ministère de ...
Mon premier framework PHP à l'époque. Sans routing donc pas d'implémentation du model REST. Des formulaires a gogo dans tous les sens même pour un pauvre menu traditionnellement construit avec des <ul><li> ...
Ma première approche du MVC a l'époque. Avec une implémentation légèrement différente en Etat / action / model de donnée / Model Métier.
J'ai ensuite utilisé un framework un peu plus moderne HMVC qui m'a permis d'y voir plus clair.
Puis avec les lenteurs d'évolution de PHP entre la version 5.x et 7, je me suis laissé tenté par un collègue a me former a Ruby On Rails ... le code est devenu des plus fluides après certains concepts apprivoisés
La console IRB / PRY pour les tests ou simuler dans une sandbox, le middleware qui s'affiche constamment dans une console pour debuguer et voir les requêtes de l'ORM passer, etc etc ...
Je continue a me former dessus et ne regrette absolument pas ce virage.
Sinon, si je devais reprendre un framework PHP a ce jour, je pense m'orienter vers Fuel PHP ou Phalcon