[MVC] code qui me semble bizarre

[Ter Rowan]

Bonjour,

j'ai cherché un module php d'authentification (histoire de pas réinventer la roue sur un truc sans intérêt, sans pour autant aller sur un framework mais chut hein sur les frameworkeuhhh) et dans mes recherches je suis tombé sur un système MVC de login

mais voilà je regarde un peu le code et je trouve quelque chose qui me semble particulier :

dans le "main"

// load the login class

require_once("classes/Login.php");



// create a login object. when this object is created, it will do all login/logout stuff automatically

$login = new Login();



// ... ask if we are logged in here:

if ($login->isUserLoggedIn() == true) {    

    include("views/logged_in.php");

    

} else {

    // the user is not logged in. you can do whatever you want here.

    include("views/not_logged_in.php");

}

et dans la view, on utilise le $login (c'est ce qui me pose souci)

// show positive messages

if ($login->messages) {

    foreach ($login->messages as $message) {

        echo $message;

    }

}

ce qui me perturbe c'est que l'inclusion de la vue correspond à du code tel quel, pouvant utiliser les variables (ici $login) générées en amont de l'inclusion.

je m'attendais plutôt à un truc du genre

$login = new Login();



// ... ask if we are logged in here:

if ($login->isUserLoggedIn() == true) {    

    include("views/logged_in.php");

    $view = new ViewLogin( $login);

    $view->render()

    

}

à savoir une instance de la view, construite à partie de l'objet login passé en paramètre

Est moi qui pense mal, est la proposition de code de la librairie qui est "baclée", est ce que les deux se valent ?

merci de vos retours !

[Xenos]

Je dirai la 2e réponse: cela ressemble à une flemmite.
Mais il s'agit du code exécuté une fois loggé, donc, la flemme peut s'expliquer parce que ce n'est pas le composant principal du "kit" (pour ne pas dire framework). Logiquement, si c'est du MVC, la solution new ViewLogin me semble plus propre, donc, en ce sens, "mieux".

[niahoo]

bah c'est du code vite fait. Utilises Twig c'est cool

[Xenos]

Twig c'est cool

Ca, c'est de l'argument >_>

[niahoo]

quand tu dis aux gens que tu aimes les pistaches tu as vraiment besoin d'argumenter au delà de "les pistaches c'est bon" ? Twig c'est sympa, à essayer.

[Roworll]

Entre les pistaches et un Framework, y'a une différence.
Les pistaches, c'est une question de goût.
Les Frameworks, c'est une question de fonctionnalité, d’accessibilité, de puissance, etc, bref, y'a matière à argumenter, ne serait-ce que pour susciter l'intérêt et faire découvrir des features particulières.

D'ailleurs, les pistaches, j'aime pô...

[srm]

Ce n'est pas gênant comme c'est fait.
Ca reste du MVC tout à fait correct.
Le render etc, ne sert à rien dans un cas aussi simple.

[Xenos]

Je suis d'accord dans le cadre d'un programme-test, mais pas dans le cas d'un programme final, Oxman. Car quand on dit "là, c'est rien, c'est pas grave de pas continuer MVC": où place-t-on la limite? A mon sens, soit on fait du "pure MVC", soit on n'en fait pas, mais un mixe des deux est le meilleur moyen de récolter les inconvénients du MVC (lourdeur) et les inconvénients du pas-MVC (maintenabilité minable).
Donc, ici, ok, pas besoin de renderer/viewer, mais non parce que c'est "un cas simple", mais parce que "c'est un cas de test, de démonstration", et que la démonstration ne porte pas sur ce bout de code.

[Sephi-Chan]

Ça ne me choque pas. C'est sûrement parce que c'est ce à quoi je suis habitué. Dans Ruby on Rails, on ne passe pas par un objet pour exposer des données à la vues : on définit juste des variable d'instance (ou attributs dans la terminologie plus classique) et elles sont accessibles dans la vue.

[niahoo]

ben comme dans twig, ou même comme dans le mini moteur de template présent sur le wiki C'est bancal d'avoir des variables dont le scope est supérieur à celui d'un fichier.