Retour sur le MVC

Mammouth du PHP | 1668 Messages

05 mars 2010, 21:13

Bonjour à toutes et à tous,

Voilà l'histoire, il y a maintenant 2-3 semaines, j'ai appris qu'un des site que je fréquentais allait passer d'un framework maison à symphony et ce dans le but d'accroitre leur rapidité de travail. Je me suis donc dis, pourquoi pas (oui, je suis très influençable des fois). J'ai donc regardé Symphony, et j'ai vu des solutions clef-en-main, ce qui ne m'a pas plût. J'ai re-jeter un œil du côté de ZendFramework : une grosse boîte à outils. Ensuite j'ai jeté un œil à HoaFramework, idem. J'ai regardé AtomikFramework, qui semble léger, voire même trop. Faisant du Ruby à mes heures perdues, je me suis penché sur RoR pour m'inspirer (pas taper). J'ai donc décidé de me lancer dans l'aventure du Framework.
But du jeu : produire un Framework léger, efficace qui me permette, une fois le gabarit du site installé, de n'avoir à me soucier que des modèles, voire des contrôleurs. Le framework aurait à coeur la hiérarchisation, la sécurité, la simplicité et les performances. Une couche "graphique/console" me permettrais de plus de générer une bonne partie de mon code.
L'un des points fort de mon futur framework est qu'il repose sur le MVC, ainsi, j'aimerais vous soumettre un exemple de code pour voir si j'applique bien de MVC.

Exemple de contrôleur :
/modules/commandes/editer.php :
<?php
/* Appel du noyau */
include '../../include.php';

/* Test des droits primaire */
if(Session::getSingleton->id == 0)
    \Base::parse('modules/membre/connexion-obligatoire.html');

/* Appel des modèles (répertoire, fichier) */
\Base::modele('commandes', 'commandes');
\Base::modele('produits', 'produits');

/* Aucune erreur */
$err = false;

if(\Base::TestForm('edite_commande', @$_POST['temps'], $err, 'paniera', 'paniern', 'produit', 'quantite'))
{
    if(\Commandes\Action\editer($_POST['produit'], $_POST['paniera'], $_POST['paniern'], $_POST['quantite']))
        \Base::parse('modules/commandes/edition-reussie.html');
    else
        \Base::parse('modules/commandes/edition-impossible.html');
}
else
{
    if(isset($_GET['panier']) && $_GET['panier'] > 0 && isset($_GET['produit']) && $_GET['produit'] > 0)
        $vue['commande'] = \Commandes\Listage\recupere($_GET['produit'], $_GET['panier']);
    else
        \Base::parse('modules/commandes/aucun-panier-commande.html');

    \Base::prepare('edite_commande');
    \Base::parse('modules/commandes/edition.html');
}

?>
Un modèle :
/modules/commandes/libs/paniers.class.php :
<?php

/**
  * Espace nom de gestion utilisateur des paniers
  *
  * @author Katagoto ([email protected])
  *
  */

namespace Paniers
{

    /**
      * Espace nom des actions sur les paniers
      *
      */

    namespace Action
    {

        /**
          * Crée un nouveau panier
          *
          * @return integer     Identifiant du nouveau panier
          */

        function creer()
        {
            return SPDO::getSingleton()->prepare('INSERT INTO
                                                paniers
                                                (fk_membre)
                                        VALUES(:fk_membre)
                                        ')
                             ->execute(array(
                                                ':fk_membre' => (integer)Session::getSingleton->id
                                            ))
                             ->fetch()
                             ->pk_panier;
        }
    }
}

Le fichier inclus partout, coeur du framework :
/include.php
<?php

/**
  * Fichier include
  *
  * @author Katagoto
  */

declare(encoding='UTF-8');
namespace
{
    session_start();

    $vues = array();

    date_default_timezone_set('Europe/Paris');

    header('Content-Type: text/html; UFT-8');

    define('ABS_DIR', $_SERVER["DOCUMENT_ROOT"].'/');

    if(!is_file(ABS_DIR.'base/base.class.php'))
        die('Le fichier des fonctions de base a disparut, le script ne peut continuer de s\'executer');
    else
        include_once(ABS_DIR.'base/base.class.php');

    Base::modele('administration', 'maintenance');
    maintenance::affiche();

    Base::modele('libs', 'sql');
    Base::modele('libs', 'session');
}
Voilà, j'attends vos réactions,

Par avance merci
"À ceux qui poursuivent leurs rêves et se spécialisent dans l'impossible" Joseph Kong

10 ans de PHP, déjà.

"moi jtrouve que katagoto il déchire!" Nagol

ViPHP
ViPHP | 1024 Messages

05 mars 2010, 21:46

Faisant du Ruby à mes heures perdues, je me suis penché sur RoR pour m'inspirer (pas taper). J'ai donc décidé de me lancer dans l'aventure du Framework.
But du jeu : produire un Framework léger, efficace qui me permette, une fois le gabarit du site installé, de n'avoir à me soucier que des modèles, voire des contrôleurs. Le framework aurait à coeur la hiérarchisation, la sécurité, la simplicité et les performances. Une couche "graphique/console" me permettrais de plus de générer une bonne partie de mon code.
L'un des points fort de mon futur framework est qu'il repose sur le MVC
Symfony :-)

Qu'est-ce qui te gène dans ce framework ?

A+

Pascal

Avatar du membre
Administrateur PHPfrance
Administrateur PHPfrance | 13231 Messages

06 mars 2010, 00:09

Faisant du Ruby à mes heures perdues, je me suis penché sur RoR pour m'inspirer (pas taper). J'ai donc décidé de me lancer dans l'aventure du Framework.
But du jeu : produire un Framework léger, efficace qui me permette, une fois le gabarit du site installé, de n'avoir à me soucier que des modèles, voire des contrôleurs. Le framework aurait à coeur la hiérarchisation, la sécurité, la simplicité et les performances. Une couche "graphique/console" me permettrais de plus de générer une bonne partie de mon code.
L'un des points fort de mon futur framework est qu'il repose sur le MVC
Symfony :-)

Qu'est-ce qui te gène dans ce framework ?

A+

Pascal
Je me suis fait exactement la même réflexion :-k
Ce que tu attends de ton framework est trait pour trait ce que propose Symfony, du coup, j'aimerais que tu précises ce qui ne te convient pas dans Symfony.
De plus, quand tu dis
J'ai donc regardé Symphony, et j'ai vu des solutions clef-en-main
je ne comprend pas, puisque Symfony est tout, sauf une solution "clé en main"
Connaître son ignorance est la meilleure part de la connaissance
Pour un code lisible : n'hésitez pas à sauter des lignes et indenter

twitter - site perso - Github - Zend Certified Engineer

Mammouth du PHP | 1668 Messages

06 mars 2010, 14:50

Après, j'ai peut-être des goût bizarre mais bon, voilà ce qui me déplait (c'est totalement subjectif, je suis d'accord) :
1. YAML et la gestion du SQL, moi j'aime bien faire du SQL en "brute", la classe de ZendFramework m'allait bien (enchainement des requêtes), en plus, je ne veut pas avoir à me soucier des erreurs dans mes méthodes.
2. La gestion des formulaires : je n'ai pas vraiment compris "l'intérêt" de faire un objet pour un formulaire, mais je suis prêt à me laisser convaincre.
3. Alors bon, là ça va être super-contesté, tout est en objet dans Symphony, moi j'aime bien, seulement, je tente de limiter au maximum avec les namespaces.

Voilà, je n'ai pas étudié profondément Symphony, donc ça peut être faux.
Je pense que les deux derniers points viennent de ma mauvaise conception du MVC je pense.

Par avance merci
"À ceux qui poursuivent leurs rêves et se spécialisent dans l'impossible" Joseph Kong

10 ans de PHP, déjà.

"moi jtrouve que katagoto il déchire!" Nagol

ViPHP
ViPHP | 2287 Messages

06 mars 2010, 15:18

je ne veut pas avoir à me soucier des erreurs dans mes méthodes.
:shock:

Il tourne en error_reporting(0) le framework ? :roll:

EDIT: Ah ok, tu parlais des erreurs dans la validation du formulaire... hein??!? :priere:
if(!@work()){ Nespresso(); } else { what(); }
______________________________

Mammouth du PHP | 1668 Messages

06 mars 2010, 16:28

Alors, pour l'édit, oui et non.
Oui dans la validation du formulaire (champs non replis, etc.).
Non, pas seulement, je pense notamment aux impossibilités de connexions SQL, pour les surcharges, les problèmes d'intégrités, etc.
La classe que j'ai actuellement bloque toutes les exceptions, et "continue".
"À ceux qui poursuivent leurs rêves et se spécialisent dans l'impossible" Joseph Kong

10 ans de PHP, déjà.

"moi jtrouve que katagoto il déchire!" Nagol

ViPHP
ViPHP | 1024 Messages

07 mars 2010, 17:59

Après, j'ai peut-être des goût bizarre mais bon, voilà ce qui me déplait (c'est totalement subjectif, je suis d'accord) :
1. YAML et la gestion du SQL, moi j'aime bien faire du SQL en "brute", la classe de ZendFramework m'allait bien (enchainement des requêtes), en plus, je ne veut pas avoir à me soucier des erreurs dans mes méthodes.
2. La gestion des formulaires : je n'ai pas vraiment compris "l'intérêt" de faire un objet pour un formulaire, mais je suis prêt à me laisser convaincre.
3. Alors bon, là ça va être super-contesté, tout est en objet dans Symphony, moi j'aime bien, seulement, je tente de limiter au maximum avec les namespaces.
alors mes réponses :
1. YAML & SQL :
YAML est un choix pour les fichiers de config, justifié par sa clarté de lecture. C'est plus lisible que XML
SQL : on peut lancer des requêtes "brutes" avec doctrine ou propel, il faut lire la doc pour ça.
2. La gestion des formulaires :
ça permet d'avancer hyper vite sur un sujet basique et présent partout. On passe rapidement du modèle de données à un formulaire personnalisé dans les pages, on enchaine ensuite en travaillant les règles de validation puis ce qu'on enregistre en base. Concrètement, on peut gérer un formulaire en une demie heure chrono.
3. les gouts et les couleurs :P

A+

Pascal

Mammouth du PHP | 1668 Messages

07 mars 2010, 19:17

Bref, pour revenir au sujet de départ, qu'est-ce qui ne va pas dans mon approche du MVC

Par avance merci
"À ceux qui poursuivent leurs rêves et se spécialisent dans l'impossible" Joseph Kong

10 ans de PHP, déjà.

"moi jtrouve que katagoto il déchire!" Nagol

Avatar du membre
Administrateur PHPfrance
Administrateur PHPfrance | 13231 Messages

08 mars 2010, 00:14

Au niveau de la couche contrôleur, je suis assez peu fan de la multiplication de petits controleurs, qui impose d'avoir toutes les inclusions, et toutes les vérifications (ACL en particulier). Je préfère de loin l'approche d'un controleur central qui sais rediriger sur le controleur adhoc.

Au niveau de la couche modèle, je trouve que ton approche "passer par les sessions pour transmettre des données du controleur au modèle" est ... surprenant. Non seulement on utilise les sessions a mauvais escient, mais il faut en plus prévoir un nettoyage de la session pour que ces données ne persistent pas d'une page à l'autre et, surtout, ta couche modèle est très dépendante de la session.

Sinon, sur le reste :
=> pour quelqu'un qui n'aime pas le tout objet, passer par un singleton pour la session est assez marrant. Toujours dans les sessions, j'ose à peine te demander le code de ta classe session, le getSingleton->id m'effrayant quelque peu :/
=> Quand tu dis "je ne veut pas avoir à me soucier des erreurs dans mes méthodes.", je suis effrayé. Comment peut on prétendre faire un code (un simple code, pas un framework) en disant ne pas gérer les erreurs :shock:

Voilà pour mon retour, en espérant que ça te permettra d'avancer.
Connaître son ignorance est la meilleure part de la connaissance
Pour un code lisible : n'hésitez pas à sauter des lignes et indenter

twitter - site perso - Github - Zend Certified Engineer

Modérateur PHPfrance
Modérateur PHPfrance | 6037 Messages

08 mars 2010, 11:18

Je crois que Symfony prend un F sinon, on parle du logiciel d'IBM

Après, j'
ai peut-être des goût bizarre mais bon, voilà ce qui me déplait (c'est totalement subjectif, je suis d'accord) :
1. YAML et la gestion du SQL, moi j'aime bien faire du SQL en "brute", la classe de ZendFramework m'allait bien (enchainement des requêtes), en plus, je ne veut pas avoir à me soucier des erreurs dans mes méthodes.
2. La gestion des formulaires : je n'ai pas vraiment compris "l'intérêt" de faire un objet pour un formulaire, mais je suis prêt à me laisser convaincre.
3. Alors bon, là ça va être super-contesté, tout est en objet dans Symphony, moi j'aime bien, seulement, je tente de limiter au maximum avec les namespaces.

Pour le 1 : des goûts et des couleurs...Symfony 2.0 revient à des fichiers de confs au choix (XML, YAML, PHP). En Zend Framework, ce sont des fichiers .ini si mes souvenirs sont bons.
2. L'intérêt des formulaires en objets est de bénéficier de l'héritage.
3. L'objet a des avantages et des inconvénients que je ne détaillerais pas ici...tu trouveras une ample documentation sur les sites appropriés.


Pour faire le tour des frameworks, il faut aussi aller voir CodeIgniter et Cake PHP, non ?
Règle n°2 du webmaster : Toujours commencer par le HTML qu'on veut obtenir....toujours ! :priere:
J'aime apprendre de nouvelles choses.

ViPHP
ViPHP | 5462 Messages

08 mars 2010, 11:56

ouai pour le ZF niveau config c'est .ini mais aussi .xml, (on peu aussi direct en PHP via array) un support du yaml est prevu

Mammouth du PHP | 1668 Messages

08 mars 2010, 20:22

Pour le 1 : des goûts et des couleurs...Symfony 2.0 revient à des fichiers de confs au choix (XML, YAML, PHP). En Zend Framework, ce sont des fichiers .ini si mes souvenirs sont bons.
2. L'intérêt des formulaires en objets est de bénéficier de l'héritage.
3. L'objet a des avantages et des inconvénients que je ne détaillerais pas ici...tu trouveras une ample documentation sur les sites appropriés.
ça y est, je suis convaincu pour les formulaires
Ma classe SQL semble plaire à tout le monde :)
Je m'explique, ma classe SQL gère les erreurs, par exemple, si un INSERT/UPDATE/DELETE ne fonctionne pas pour une question de clef étrangère, de contrainte d'unicité ou d'intégrité, l'erreur sera intercepté et le rowCount sera placé à 0, du coup, je saurais que l'instruction n'a pas pût être réalisé, et je le signalerais à l'utilisateur : "Il est interdit de poster ici".
Seulement, au lieu d'avoir un catch, systématique, je l'ai dans ma classe SQL, je prends ça comme une gestion centralisé des erreurs.
Je prends note.
Oui, ça m'avance beaucoup, seulement, hors-mit l'id du membre, je ne donne rien d'autre (j'ai fais un __get de plus), je ne vois pas vraiment où est le mal.

Par avance Merci
"À ceux qui poursuivent leurs rêves et se spécialisent dans l'impossible" Joseph Kong

10 ans de PHP, déjà.

"moi jtrouve que katagoto il déchire!" Nagol

Eléphant du PHP | 453 Messages

08 mars 2010, 22:04

Ça faisait longtemps que je n'avais pas lu un sujet sur les frameworks

Hello tout le monde,
[...]
3. L'objet a des avantages et des inconvénients que je ne détaillerais pas ici...tu trouveras une ample documentation sur les sites appropriés.
[...]
Aurais tu un/des petits liens à partager stp. J'ai lu il y a quelques temps que php en full objet n'est pas une si bonne pratique. Cependant, il n'y avait pas d'argument derrière. Donc, je me retrouve avec un gros point d'interrogation à ce propos.
[...] Cake PHP, non ?
Pour ma part, je connais un tout petit peu cake. J'ai trouvé ça pas mal (Cake Bake permet de créer une interface (édition à la volée du MVC) en exécutant 2 commandes à partir de cet utilitaire). Soucis temps d'exécution des requêtes. Un peu mou le gâteau (fondant au chocolat). Avec l'OS actuel, je n'ai pas installé APC. Donc le temps est un peu long. À première vue, Cake on s'y retrouve très facilement dossier : modèles, contrôleurs et vues. Je crois que Cake se focalise plutôt dans l'aspect visible de l'application (html/css/javacript/("Flash")) et est pour des applications moyennes (là, je m'avance un peu).

Pour Symfony, j'ai laissé tombé. Symfony ne s'installe pas facilement sur Windobe (heu windows). :p. Je me suis dit que je n'allai pas mettre trois plombes à installer symfony. J'ai l'impression que c'est une formule 1 au démarrage lent (miser sur le long terme). Je ne connais pas le YAML, mais j'en ai déduis que c'était la même chose que l'XML. Si je me trompe merci de me reprendre. :)

Après je pense que Symfony est plutôt le Framework du moment (le moment à 4/5 ans je crois quand même). Aussi, j'ai vu que ce dernier récupère pas mal de choses (smarty, librairies zend, etc.). Donc j'ai l'impression qu'il prend le meilleur (ce qui est normal). Aussi, faudrait voir sa notoriété/reconnaissance dans le monde (Zend vs Symfony). Dans le cas où on veut s'expatrier et être reconnu.

Pour ma part, je pencherai plus sur PEAR et Zend. Pear ne risque pas de se casser la gueule et est constamment en renouvellement (voir les MAJ constantes). Tandis que Zend est le Framework PHP par excellence (moteur Zend, applications Zend, bouffe du Zend à tout va). ça me fait pensé à crosoft.

Sinon, il y a un Framework qu'on parle très peu et qui est très utilisé aussi en France, c'est le perroquet red (Copix). Il est utilisé dans la plupart des administrations de notre chère République. D'ailleurs, je crois que les développeurs de ce projet étaient de la team de codeIgniter. Je crois aussi que c'est le plus vieux Framework. Quoique Pear est peut être aussi vieux.

Après faut du temps pour appréhender un Framework. Et surtout faut pas lâcher l'affaire quand on étudie un tel Framework.

Bonne soirée à vous :)

ps : Il serait surement intéressant de lancer un sondage sur phpfrance :
Quel Framework utilisez vous ?
Symfony, Zend, Copix, Cake, Pear, Codeigniter, etc., aucun.

Je pense qu'on éviterait peut être les questions redondantes du forum.
La Tux attitude avec les kiw'z syou plait
Komodo Edit - Inkscape - Dia

Avatar du membre
Administrateur PHPfrance
Administrateur PHPfrance | 13231 Messages

09 mars 2010, 00:24

Sinon, pour en revenir au sujet de base, la question était "Que pensez vous de l'approche de katagoto sur le MVC" ;)
Connaître son ignorance est la meilleure part de la connaissance
Pour un code lisible : n'hésitez pas à sauter des lignes et indenter

twitter - site perso - Github - Zend Certified Engineer

Mammouth du PHP | 1668 Messages

09 mars 2010, 07:54

La vrai question est "est-ce que l'implémentation MVC de katagoto est correcte et complète ?"

Hier soir, j'ai eu la chance de parler à HyWaN et Nagol.
Je ne vous cacherais pas que j'ai eu un moment de doute métaphysique.
Cependant, j'ai remarqué qu'un contrôleur par module, réunion des contrôleurs dans un objet, n'était pas si mal.
En revanche, je pense que l'impacte, en terme de performances, de l'objet sur PHP est considérable, d'où ma tentative de limitation de ceux-ci.

Par avance merci

PS : Ma classe SQL ne vous gène plus ? (je peux ré-expliquer)
"À ceux qui poursuivent leurs rêves et se spécialisent dans l'impossible" Joseph Kong

10 ans de PHP, déjà.

"moi jtrouve que katagoto il déchire!" Nagol