[MVC] code qui me semble bizarre

[Myrina]

Le pattern MVC est respecté; par contre, c'est l'injection de dépendances qui n'est pas faite.

[srm]

Tout à fait Myrina.
C'est ce que j'expliquais Xenos, je n'ai jamais dit que le pattern MVC n'était pas respecté, j'ai dit au contraire qu'il l'était.
Et que par exemple faire de render ou je ne sais pas quoi, ça a aucun rapport avec le pattern MVC.
Dans l'exemple donné chaque couche fait bien son boulot et que son boulot, on est donc dans un MVC propre.

[Xenos]

Je ne suis pas bien d'accord (ou alors, j'ai mal compris le code), car pour moi, $login est le modèle et il me semble assez étrange d'avoir un morceau de code dans la vue qui tape directement sur un attribut du modèle. Le $login->message me gène. Plus le fait que, au vue de l'exemple donné, on ne peut pas savoir si $login est vue comme une variable globale, ou comme un objet attaché à la vue.

[Ter Rowan]

pour avoir le code complet, clique sur login, dans mon post initial, tu as le code complet

[srm]

Ca te semble peut-être étrange, pourtant c'est tout à fait normal.
Que la vue lise directement le model est tout à fait classique est partie intégrante du MVC.
Qu'en général les frameworks ne font pas exactement ça, ne veut pas dire que lorsque tu le fais tu es pas dans du MVC.
Je t'invite à relire http://fr.wikipedia.org/wiki/Mod%C3%A8le...%C3%B4leur
Ou à regarder ça si tu as la flemme de lire :

[Xenos]

En PHP, n'ayant pas de variable read-only, un "$login->message" accessible depuis la vue me semble permettre également un "$login->messages = "... Donc, la vue a les droits pour écrire le modèle, ce qui me semble pas très correct (d'accord, "le développeur, promis, il le feras pas"... Mais j'ai des doutes quand même! sinon, on n'aurait pas de private/protected/public si on faisait 100% confiance aux dev).

Probablement à cause du stage, j'ai plutôt ca en tête

Où les éléments sont bien plus découplés les uns des autres (mais au fond, c'est plutôt parce que MVC & loose coupling sont utilisés de concert).

Bon, quand au code complet, je n'avais pas vu, merci Ter Rowan.

[edit] Ou alors, on passe par le getter magique, mais je trouve que c'est franchement pas très joli.

[niahoo]

au contraire le getter magique c'est fait pour ça. et sinon tu fous un underscore devant le nom de ta variable comme ça le développeur est prévenu.

[Xenos]

Mouais... Il n'empêche qu'avec ce système, le couplage entre les morceaux de code est hyper fort...
Admettons, si je veux changer le nom de mon attribut "message" en "messages", il va falloir se taper tout le code pour trouver les "$login->message" et les remplacer? Alors, ok, on va me répondre "OSEF, y'a le refactoring". Mais donc, impossible de publier le soft en Open Source, car l'option de refactoring de ton éditeur ne va pas toucher les codes des autres utilisateurs (qui devront donc faire le refactoring eux-mêmes, donc, y'a duplication d'opérations entre les différents projets).
Ou alors, il faut une forme de "redirection" dans ton getter magique, qui renverrait les appels à $login->message vers $login->messages... En ce cas, on se retrouve avec des pépins qui trainent de ci de là dans le code, et qui non seulement le rendent dégueulasse, mais également le ralentissent, et surtout, finiront par le rendre impossible à maintenir dans l'avenir...

Quand à "l'underscore ca prévient le développeur", c'est une solution de forme, pas de fond... C'est aussi pertinent que de créer des variables avec un nom en majuscules, et de dire "c'est des majuscules, donc, c'est une constante"... Soit le développeur, soit le "hacker" pourra changer ces règles sans soucis. Et aussi, tu comptes faire 60 pages de spécifications pour dire "majuscules = constante, underscore = read only, deux underscore = write only, underscore et majuscules = read only et constante, underscore puis P puis underscore, puis K = paramètre kernel"...
C'est pas franchement propre je trouve, et le loose coupling, tu peux le mettre aux toilettes et tirer la chasse !

Je ne trouve pas l'argument du "tu fous un underscore" viable, c'est un peu comme dire "tu fous ton HTML dans un tableau et voilà, t'as ta présentation" ou "tu ajoute un GIF transparent et c'est réglé pour le positionnement"... Ca, y'a 10 ans, on trouvait que c'était bien, et maintenant, on a compris que c'était totalement dégueulasse.

[niahoo]

de toute façon, quand tu vas passer un objet à ta vue, que ce soit un array, un objet avec une propriété ou avec une méthode, si jamais 'message' devient 'messages' il faudra bien modifier les appels. Que ce soit $login['messages'], $login->messages ou $login->getMessages(), ça ne change rien. Donc je ne vois pas où tu veux en venir.

Quant au reste, on appelle ça des conventions. Dans le monde python, un membre précédé d'un underscore signifie un membre private. Comme ça n'existe pas les private en python, c'est une convention indiquant un membre auquel il ne faut toucher que si on sait ce qu'on fait.

En Javascript, quand tu commences une variable par une majuscule, cela signifie que c'est un constructeur à appeler avec l'opérateur 'new'. Cette convention existe pour ne pas oublier d'utiliser 'new', sans quoi 'this' dans le constructeur modifierait l'objet global.

En PHP, il y a une convention qui veut qu'on préfixe les membres privés avec un underscore. C'est stupide (caractéristique des PHP fanboys) puisque la variable étant privée on ne peut de toute façon pas y toucher. Mais certaines personnes ont pris exemple sur python et on préfixé des variables public ou protected pour indiquer, encore une fois, qu'il faut y toucher seulement si on sait ce qu'on fait.

Et c'est bien car ça permet de donner la possibilité au développeur averti tout en prévenant le développeur candide d'éventuels dégâts. ça s'appelle une convention et il en existe des dizianes dans le développement informatique. Décaler un bloc avec un GIF ça s'appelle ne pas savoir comment faire. Protéger des membres publics en prévenant ça sert à permettre à ceux qui savent faire de faire. ça n'a rien à voir.

[Xenos]

de toute façon, quand tu vas passer un objet à ta vue, que ce soit un array, un objet avec une propriété ou avec une méthode, si jamais 'message' devient 'messages' il faudra bien modifier les appels. Que ce soit $login['messages'], $login->messages ou $login->getMessages(), ça ne change rien. Donc je ne vois pas où tu veux en venir.

Tu peux parfaitement: soit garder getMessages() renvoyant $login->messages, soit ajouter getMessage() et indiquer que "getMessages" est en phase d'être obsolète (et elle renvoie à getMessage).

Mouais, pour la convention, je ne suis pas d'accord... Ok, ca permet au "développeur avertis" de pas s'emmêler les pinceaux, mais ca n'a pas plus de poids qu'un feu rouge clignotant à un passage à niveau. S'il n'y a que le feu, certains passeront quand même, soit volontairement par défi (hacking?) soit involontairement parce qu'ils sont simplement aveugles (bugs).
Quand, comme en Python, y'a pas de private, ok, on peut "bricoler" avec la convention, mais cela ne "génère" pas le private. Le private, c'est effectivement 50% de "j'suis développeur et j'dois pas toucher à cela", mais cela compte aussi en terme de sécurité. Par exemple, un attribut privé "password" stocké dans l'objet pourrait être lu... Dans PHP aussi, ok, mais dans d'autres langages, on ne peut pas lire la variable (ou alors, il faut passer par bien plus lourd qu'un simple morceau de code dans le programme). En C++ par exemple, si tu n'as pas le code source de l'objet qui contient le "private", alors tu ne pourras pas le lire, nul part dans le code.
Dans le cas de PHP, un attribut comme "URL" pourrait être problématique s'il n'est pas en "écriture privée": un développeur malveillant pourra changer l'URL de l'objet, qui renverra peut-être le serveur ou le client ailleurs que sur le site désiré.

La convention me semble donc être un "bricolage", acceptable faute de mieux, mais là en PHP, je trouve qu'il y a mieux.
Mais c'est une impression personnelle peut-être.