Mise en place du MVC sur un site : problème de visibilité de variables

Mise en place du MVC sur un site : problème de visibilité de variables - PHP - Programmation

Marsh Posté le 29-10-2006 à 18:49:54    

Bonsoir tout le monde,
 
Je passe par là car j ai un petit problème de visibilité pour mes variables lors de la creation du noyau de mon site en version Model-View-Controller (MVC pour les intimes)
 
Petite explication :
Le contrôleur (Controller) traite les informations à partir des données du modèle (Model), et renvoi un résultat sous forme de variables à la vue (View)
 
Mon problème :
Je veux initialiser des variables (par exemple $monTableau) à partir de la fonction $monObjet->maFonction() et avoir accès à cette variable dans le fichier View (qui sera inclus via un requiere_once() ) en appelant simplement $monTableau["maDonnée"]
 
Je précise que je ne veux pas passer par $GLOBALS[];
 
Connaissez vous un moyen de remplir $monTableau depuis une fonction sans passer par $GLOBALS[] ni le mot clef global ?
 
 
merci d avance pour vos réponses

Reply

Marsh Posté le 29-10-2006 à 18:49:54   

Reply

Marsh Posté le 29-10-2006 à 18:57:21    

Déclare la variable dans le scope local, juste avant de faire le require [:dawak]

Reply

Marsh Posté le 29-10-2006 à 20:58:35    

les variables étant définies dynamiquement, je ne peux pas les déclarer avant le requiere... malheureusement...
 
La seule solution que j'ai est la déclaration depuis $monObjet->maFonction()
... une solution ???

Reply

Marsh Posté le 29-10-2006 à 20:59:53    

Je pige pas trop ta structure là :/ Ca m'a l'air assez le bordel

Reply

Marsh Posté le 29-10-2006 à 21:02:46    

ah les joies du php ou chacun bricole un framework dans son coin  :love:

Reply

Marsh Posté le 29-10-2006 à 22:16:55    

ok j'ai résolu mon problème via des inclusions dynamiques à l'intérieur des fonctions... c'est compliqué mais ca marche :)

Reply

Marsh Posté le 30-10-2006 à 00:57:27    

Au lieu de faire:

Code :
  1. <h1>$titre</h1>


 
pourquoi pas faire:

Code :
  1. <h1>$donnee->titre</h1>


 
Quand c'est compliqué, généralement c'est que y'a un truc qui est foireux derrière :whistle:

Reply

Marsh Posté le 30-10-2006 à 10:47:42    

Citation :

Quand c'est compliqué, généralement c'est que y'a un truc qui est foireux derrière :whistle:


 
ouép, enfin les gros projets sont toujours complexes (regarde les sources d'apache par exemple  :pt1cable: )

Reply

Marsh Posté le 30-10-2006 à 13:06:24    

Sliver373 a écrit :

Citation :

Quand c'est compliqué, généralement c'est que y'a un truc qui est foireux derrière :whistle:


 
ouép, enfin les gros projets sont toujours complexes (regarde les sources d'apache par exemple  :pt1cable: )


Mouais, enfin après si tu découpes la chose correctement, chaque morceau est un petit problème simple perdu dans un problème immense que tu vois plus [:petrus75]

Reply

Marsh Posté le 30-10-2006 à 13:20:05    

Sliver373 a écrit :


Le contrôleur (Controller) traite les informations à partir des données du modèle (Model), et renvoi un résultat sous forme de variables à la vue (View)


le controller qui traite les informations ? oO c'est pas son rôle. Ou alors j'ai pas compris ce que tu veux dire. Le controller peut récupérer les données émises par l'utilisateur, en effet, mais c'est le model qui les traite.
Le controller qui renvoit les résultats à la vue sous forme de variables ? C'est pas son rôle. La vue récupère directement les données depuis le model, et elle sait comment le faire (la vue est totalement dépendante du model). Le controller n'est pas un médiateur qui balance les données du model vers la vue.  
 
 
Tes problèmes viennent d'une structure incorrect je pense.

Reply

Marsh Posté le 30-10-2006 à 13:20:05   

Reply

Marsh Posté le 31-10-2006 à 15:27:23    

c'est une approche du MVC... on peut en avoir d'autres.
En fait la mienne est plus automatisée pour simplifier le boulot des programmeurs, et se rapproche plus de ca (merci FlorentG)
 
http://img243.imageshack.us/img243/4794/mvcum0.png

Reply

Marsh Posté le 31-10-2006 à 16:33:24    

Mon schéma pourrave :D Faut que je l'améliore un peu...

Reply

Marsh Posté le 01-11-2006 à 17:43:54    

Je croyais que la view recuperait du model

Reply

Marsh Posté le 01-11-2006 à 18:40:43    

Concretement ca sert a quoi tout se merdier :D
 
J'ai jamais compris l'interet si qqun peux m'expliquer ca succintement je suis preneur :p


---------------
Comme dirait quelqu'un de beaucoup plus avisé que moi, quelquefois c'est toi qui cognes le bar mais d'autres fois, et ben, c'est le bar qui te cogne.
Reply

Marsh Posté le 01-11-2006 à 19:22:54    

Moi aussi j'ai commencé a me pencher la dessus, je vais tenter de t'expliquer brièvement.
 
Framework = cadre de travail.
 Tu imagines ça comme un cadre de travail supposer faciliter le dev de ton application. Une caisse à outil par exemple est un framework pour l'artisan.
 
Tu prends le schéma logique procédural de base :
 
user_request -> application -> output
 
La requete user entraine le lancement de ton application, puis le choix de l'action à lancer ( Controller ), puis la logique interne et l'accès donnée ( model ) et enfin l'affichage sur un media de sortie (View).
 
Maintenant le souhait des developpeurs est de séparer dans la limite du possible en trois phases ton aplication de facon à ne plus avoir un script qui gère tout d'un coup.
Cf. : séparation en couche. (TCP/IP, noyau/système, framework)
 
Pourquoi séparer ?
=> Evolution d'une application : la modification devient hypothétiquement plus facile dans la mesure ou tu sais à priori ou maximiser tes efforts.  
Analogie: Tu souhaites rajouter une clé à molette à ta caisse d'outils. La clé à molette est un outil "indépendant" susceptible de servir à plusieurs tache. Donc tu la mets dans la case "outil independant susceptible de servir à plusieurs tache" ( model ).
 
Par contre si la caisse à outil à un seul casier et que tu disposes de 100 outils, ca va etre plus dur de retrouver ta clé à molette.
 
=> Maintenance hypothétiquement plus simple : dans la mesure ou chaque script/classe est rangée correctement dans son casier, il devient plus simple de retrouver une source de problème.
 
=> Ton framework t'offre des outils basiques très utiles pour ton application:
Par exemple une classe d'accès SQL, ou une classe de log, ou une classe de filtrage ou autre chose que tu utilises systématiquement dans tes applications.
Un exemple simple: tu as developpé une super classe de filtrage et tu en as toujours besoin. Tu l'intègres à ton framework dans la partie outils  indépendant ( model ) et tu en profites pour toutes tes prochaines applications.
 
Le schéma logique d'un MVC serait donc comme ceci:
 
controller: traduit les données utilisateurs pour le traitement interne fait par le modele
modele: collection d'outils du framework sensé vivre en autharcie
vue: recupere les données du modele est les traduit sur un media de sortie
 
user_request -> controller -> model -> view -> output
 
Pour conclure proprement: les flux representés ci dessus doivent être normalisés parfaitement. Plus l'information qui transite entre tes objets/script est similaires plus la maintenance sera simple.
L'abstraction est donc le maitre mot pour implémenter un framework fiable et pour ceci tu as PHP 5 orienté objet.
 
Voila sinon il faut aller voir le post de FlorentG.


Message édité par supermofo le 01-11-2006 à 19:33:26
Reply

Marsh Posté le 02-11-2006 à 01:23:56    

C'est donc utile dans le cas de projet plus que consequent :)
 
Je vais peut etre me pencher sur la question, mais je doute par rapport à la complexité de structure que ça entraine, et le gain final.


---------------
Comme dirait quelqu'un de beaucoup plus avisé que moi, quelquefois c'est toi qui cognes le bar mais d'autres fois, et ben, c'est le bar qui te cogne.
Reply

Marsh Posté le 02-11-2006 à 01:41:25    

Kyfun a écrit :

C'est donc utile dans le cas de projet plus que consequent :)
 
Je vais peut etre me pencher sur la question, mais je doute par rapport à la complexité de structure que ça entraine, et le gain final.


Les gains déjà évoqués: reutisabilité, facilité de maintenance et d'évolution, séparation des problématiques métier de l'affichage (qui peut changer au gré des saisons et de ton imagination, seul l'affichage change, tu touches pas le traitement, juste le fichier gérant la page en question par exemple)...
 
Y'a surement de la perte qui est la même que pour un framework (mvc est un concept de développement, pas un framework, même si ça pousse à la généricité/réutilisabilité): trop de code mort, générique, stucture complexifiée...
 
Faut juste pas tomber dans l'extrêmisme comme pour tout, et voir où t'as plus à perdre qu'à gagner ;)

Reply

Marsh Posté le 02-11-2006 à 01:54:38    

Puis surtout PHP, c'est vraiment tres crado.
Tu t'imagines un paquet de merde, si t'as pas une structure solide pour la contenir ben ça degouline et t'en fous partout.
Si t'utilises un MVC et un framework solide, ben t'as de la merde parfumé. C'est pas plus solide, mais au moins ça pue pas.

Reply

Marsh Posté le 02-11-2006 à 02:13:49    

subtil a écrit :

Puis surtout PHP, c'est vraiment tres crado.
Tu t'imagines un paquet de merde, si t'as pas une structure solide pour la contenir ben ça degouline et t'en fous partout.
Si t'utilises un MVC et un framework solide, ben t'as de la merde parfumé. C'est pas plus solide, mais au moins ça pue pas.


 :sarcastic:  
Forcément si c'est pas du C++ ou du java c'est de la merde c'est ça :??:  :kaola:  
 
Là tu pars loin dans le HS, PHP est de loin (et s'améliorant de jour en jour) le langage le plus adapté au web dynamique n'en déplaise aux puristes pas capables de coder proprement si on leur met pas un compilateur sévère au parsage :whistle: C'est pas au compilateur/parseur/évaluateur de t'apprendre à coder proprement, le fait est que c'est plus dur de faire de la merde en java qu'en php, mais cela ne veut pas dire que java est mieux (à quel niveau :??: ) que php :spamafote:

Reply

Marsh Posté le 02-11-2006 à 02:24:00    

C++ appartient au passé. JAVA est en train de perdre la guerre.
PHP a plein de petits soldats qui ne savent pas se battre et 0 artillerie derriere.

 

.NET vaincra!

Reply

Marsh Posté le 02-11-2006 à 03:28:24    

subtil a écrit :

C++ appartient au passé. JAVA est en train de perdre la guerre.
PHP a plein de petits soldats qui ne savent pas se battre et 0 artillerie derriere.
 
.NET vaincra!


:lol:
 
Surtout quand on sait que Microsoft bosse avec phpgroup pour tout pêter avec iis7 + php  :ange:  
 
Un framework c'est beau mais qui a envie sous prétexte de pas réinventer la roue de s'astreindre à la volonté à tourner sous windows et de faire du lourd :??:
 
.NET (ou le C# si tu préfères :whistle: ) est mort le jour où on l'a pensé ;) C'est bien, c'est beau, c'est top pour ceux qui veulent du lourd propriétaire. Malheureusement, on veut du léger, évolutif, gratuit (pour ceux qui peuvent pas lâcher des centaines de milliers d'€) avec surtout du développement rapide, en mode XP plus adapté aux demandes (qui veux un truc qui s'étend sur 2 ans sans voir le moindre bout de code utilisable pour arriver à un truc qui correspond pas :??: ).
 
En tous cas on parle de web et .NET pour le web :lol:
 
Même Microsoft à compris qu'il vaut mieux vendre de la plateforme performante sans rien d'autre pour concurrencer le libre alors réveilles toi  :ouch:  
 
PS: je suis un pro windows pour la facilité d'accès et d'utilisation mais anti-truc-qui-fait-tout-pour-toi-parce-que-t'es-une-feignasse ;)

Reply

Marsh Posté le 02-11-2006 à 07:11:37    

Kyfun a écrit :

C'est donc utile dans le cas de projet plus que consequent :)
 
Je vais peut etre me pencher sur la question, mais je doute par rapport à la complexité de structure que ça entraine, et le gain final.


 
 
C clair, t'as completement raison. En plus vu que le terme conséquent est relatif selon qu'on maitrise ou pas deja le procedural classique.
 
Dans tous les cas je pense qu'il est inutile de se lancer la dedans si le produit final n'utilise pas les dernières fonctionnalites SOAP et XML de php 5.
 
Par contre pour une equipe de developpeur il me semble que définir un bon framework est essentiel ( mais on peut toujours s'en sortir avec de bonnes vielles collections de librairies ).
 
Edit: plus lent que java ca existe ? Oui, Ruby on rail  :sleep:


Message édité par supermofo le 02-11-2006 à 11:05:39
Reply

Marsh Posté le 02-11-2006 à 12:58:35    

Supermofo : Voila, c'est ce que je pense effectivement, il peut vite devenir essentiel d'avoir un framwork pour une équipe, mais pas pour un projet solo, même de taille moyenne. Jvois franchement pas d'enorme avantage. Par contre niveau dev ça risque d'être légerement plus long :D
 
Subtil : PHP crado ? C'est qu'on a pas du t'apprendre certaine règle élèmentaires de dev :D. Que ce soit du c ou du java, jpeux te faire du code crado en 2s. Suffit d'avoir quelque règle de base. Si tu trouves le php crado, c'est p'tetre que tu les as pas :)
Le troll était bien lancé, mais un peu faiblard quand meme :p


Message édité par Kyfun le 02-11-2006 à 12:59:07

---------------
Comme dirait quelqu'un de beaucoup plus avisé que moi, quelquefois c'est toi qui cognes le bar mais d'autres fois, et ben, c'est le bar qui te cogne.
Reply

Marsh Posté le 02-11-2006 à 14:09:45    

VENEZ DANS MON TOPIC §§§

Reply

Marsh Posté le    

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed