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

Déclare la variable dans le scope local, juste avant de faire le require

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

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

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

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

Au lieu de faire:

 
pourquoi pas faire:

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

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

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

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.

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)
 

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

Je croyais que la view recuperait du model

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

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.

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

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.

   
Forcément si c'est pas du C++ ou du java c'est de la merde c'est ça    
 
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 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

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!

 
Surtout quand on sait que Microsoft bosse avec phpgroup pour tout pêter avec iis7 + php    
 
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 ) 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
 
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    
 
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

 
 
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  

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
 
Subtil : PHP crado ? C'est qu'on a pas du t'apprendre certaine règle élèmentaires de dev . 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

VENEZ DANS MON TOPIC §§§