Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
1439 connectés 

  FORUM HardWare.fr
  Programmation
  PHP

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

 


 Mot :   Pseudo :  
 
Bas de page
Auteur Sujet :

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

n°1467036
Sliver373
Posté le 29-10-2006 à 18:49:54  profilanswer
 

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

mood
Publicité
Posté le 29-10-2006 à 18:49:54  profilanswer
 

n°1467038
FlorentG
Unité de Masse
Posté le 29-10-2006 à 18:57:21  profilanswer
 

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

n°1467087
Sliver373
Posté le 29-10-2006 à 20:58:35  profilanswer
 

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 ???

n°1467088
FlorentG
Unité de Masse
Posté le 29-10-2006 à 20:59:53  profilanswer
 

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

n°1467092
subtil
Posté le 29-10-2006 à 21:02:46  profilanswer
 

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

n°1467109
Sliver373
Posté le 29-10-2006 à 22:16:55  profilanswer
 

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

n°1467148
leflos5
On est ou on est pas :)
Posté le 30-10-2006 à 00:57:27  profilanswer
 

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:

n°1467246
Sliver373
Posté le 30-10-2006 à 10:47:42  profilanswer
 

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

n°1467379
leflos5
On est ou on est pas :)
Posté le 30-10-2006 à 13:06:24  profilanswer
 

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]

n°1467398
Djebel1
Nul professionnel
Posté le 30-10-2006 à 13:20:05  profilanswer
 

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.

mood
Publicité
Posté le 30-10-2006 à 13:20:05  profilanswer
 

n°1468254
Sliver373
Posté le 31-10-2006 à 15:27:23  profilanswer
 

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

n°1468330
FlorentG
Unité de Masse
Posté le 31-10-2006 à 16:33:24  profilanswer
 

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

n°1468747
supermofo
Hello World !
Posté le 01-11-2006 à 17:43:54  profilanswer
 

Je croyais que la view recuperait du model

n°1468777
Kyfun
Les choses se passent !
Posté le 01-11-2006 à 18:40:43  profilanswer
 

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.
n°1468800
supermofo
Hello World !
Posté le 01-11-2006 à 19:22:54  profilanswer
 

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
n°1468946
Kyfun
Les choses se passent !
Posté le 02-11-2006 à 01:23:56  profilanswer
 

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.
n°1468948
leflos5
On est ou on est pas :)
Posté le 02-11-2006 à 01:41:25  profilanswer
 

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

n°1468949
subtil
Posté le 02-11-2006 à 01:54:38  profilanswer
 

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.

n°1468952
leflos5
On est ou on est pas :)
Posté le 02-11-2006 à 02:13:49  profilanswer
 

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:

n°1468955
subtil
Posté le 02-11-2006 à 02:24:00  profilanswer
 

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!

n°1468964
leflos5
On est ou on est pas :)
Posté le 02-11-2006 à 03:28:24  profilanswer
 

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

n°1468971
supermofo
Hello World !
Posté le 02-11-2006 à 07:11:37  profilanswer
 

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
n°1469218
Kyfun
Les choses se passent !
Posté le 02-11-2006 à 12:58:35  profilanswer
 

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.
n°1469258
FlorentG
Unité de Masse
Posté le 02-11-2006 à 14:09:45  profilanswer
 

VENEZ DANS MON TOPIC §§§

mood
Publicité
Posté le   profilanswer
 


Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Programmation
  PHP

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

 

Sujets relatifs
Probleme Requette SQLproblème php/mysql : mysql_connect()
Besion d'aide pour l'édition d'un site.Probleme avec un code....
FAILLE sur le site de ma fac...Probleme de NULL INTERDIT dans une table
Créer une interface admin sur son siteprobleme avec simplexml
Probleme de requete[C# ASP.Net] Problème lors de l'envoi d'un email
Plus de sujets relatifs à : Mise en place du MVC sur un site : problème de visibilité de variables


Copyright © 1997-2022 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR