Discussion :

[DrWilly]

Bonjour à tous,

Je souhaite mettre en pratique un petit exemple de modèle MVC très souple mais je bloque sur l'endroit ou effectuer les traitement de boucle lors de l'affichage.

L'exemple peux être trouvé ici :
http://fr.wikibooks.org/wiki/Program...P/Exemples/MVC

J'apprécie particulièrement cet exemple car il est vraiment très modulable.
Les différents composant sont appelé dans chaque page php (pas de controller unique donc) de cette manière dans mon application :

acceuil.php

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
 
<?php
 
// Main page
 
# INIT
	@session_start(); 
 
# PREPARE PAGE
 
	$page['container']['header']='<p>ceci est le header<p/>';
	$page['container']['footer']='<p>ceci est le footer<p/>';
 
	// appel du Controller Principal
	require_once "./control/controller.inc.php";
 
	// Appel des vues souhaitées
	require_once './view/page/articleView.inc.php';
	// 		preparation du container principal
	$page['container']['main']=$page['container']['test'];
 
# OUTPUT final
 	require_once './view/frameSet/mainFrameSet.inc.php';
 
	echo $page['container']['frameSet'];
 
?>

Ici, les pages sont donc appelée chacune directement et non pas en passant par un controler "index.php" comme on peux le voir parfois (avec "index.php?page=maPage" par exemple). Chaque fois qu'une page est appelée, elle va elle même inclure les composants qu'elle souhaite utiliser.

Ca peux être un header ou/et un footer, un controller général ou/et particulier, certains composant de vues et enfin un frameSet générique ou spécifique qui va tout mettre en forme. Pratique et souple donc, pour peux que l'on soit en présence d'une application non orienté métier ou l'on préférera un framework plus complet. Ce qui est n'est pas mon cas ici.

Mon problème est ici que je ne vois absolument pas ou effectuer les traitement qui vont influencer la génération de la vue. Une boucle pour afficher les articles par exemple, ou une condition pour afficher un message ou non.

La confusion viens justement de cette page *.php qui n'a pas vraiment de statut. Fait elle partie de la vue ? Si c'est le cas, doit on mettre les traitement php dedans et appeler à chaque fois des petit bout de vue ? Ca ne semble pas très pratique... De plus, j'aimerais bien n'y mettre que les appel aux différents composants. A contrario, faudrait-il mettre ces traitement dans les composant de la vue (ici "articleView") ? Mais on mélangerais les traitement et les affichage alors.. et puis ce n'est pas du tout pratique vu que l'ensemble des affichage d'un composants de la vue doit être contenu dans une variable (ici $page['container']['test']), ce qui sous-entend qu'on ne doit y mettre que du HTML pur..!

En Java/JSF par exemple, les vues sont les pages appelées. Les boucles s'effectue donc dans ces pages avec des instruction spécifique. Mais ici vue et page appelée semblent séparées.

Bref tout cela semble prometteurs mais je sèche quand il s'agit d'aller plus loin que ce que l'exemple propose. L'affichage d'une liste d'article par exemple.

Des idées ? Ce modèle simple est un parfait compromis pour mettre en place facilement une structure MVC, sans pour autant s'y connaitre en POO.

Merci beaucoup.

[metagoto]

En Java/JSF par exemple, les vues sont les pages appelées. Les boucles s'effectue donc dans ces pages avec des instruction spécifique. Mais ici vue et page appelée semblent séparées.

Bref tout cela semble prometteurs mais je sèche quand il s'agit d'aller plus loin que ce que l'exemple propose. L'affichage d'une liste d'article par exemple.

Des idées ? Ce modèle simple est un parfait compromis pour mettre en place facilement une structure MVC, sans pour autant s'y connaitre en POO.

Franchement, c'est exemple de MVC est mauvais (je parle du tuto que tu as donné en lien). Non pas parce qu'il ne fait pas intervenir de POO (au contraire, c'est tout à son honneur), mais parce qu'il est bancal et bourré de trous de sécurités élémentaires!

En fait tu as répondu à ta question: "les vues sont les pages appelées. Les boucles s'effectue donc dans ces pages avec des instruction spécifique".
Là c'est pas commode du tout car les déclarations des fragments de vue sont placés dans un array.
Pour commencer, tu pourrais réarranger le code de manière à virer ces déclarations dans des array. Au lieu d'avoir:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
// vueMachin.php
$page['container']['visa']='
  <div id="cVisa">.....
  </div>';

Tu aurais un 'vrai' fichier de templates:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
// vueMachin.php
 
<div id="cVisa">
<?php foreach(...):?>
...boucle sur tes trucs etc
<?php endforeach; ?>
</div>

Récupérer cette sortie à l'aide de ob_start()/end_clean(), du genre:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
ob_start();
include 'vueMachin.php'
$page['container']['visa'] = ob_get_clean();

Ce mécanisme (juste au dessus, là ^) pourrait/devrait être centralisé pour tous les fragments constituants une même page. Ensuite la partie "application" pour telle ou telle page demandée appellerait ce système de génération de fragments.

[nours312]

il semblerait que la page index.php que tu souhaites éliminer soit remplacer par celle que tu utilise ... tout simplement ^^

comme on peux le voir parfois (avec "index.php?page=maPage" par exemple). Chaque fois qu'une page est appelée, elle va elle même inclure les composants qu'elle souhaite utiliser.

en effectuant un petit urlRewriting, tu peux trés facilement transcrire une url demandée (mondomaine.com/mesArticles/page3.html) en index.php?controller=mesArticles&param=page3

ce qui te permet dans ton fichier index.php d'apeller ton controller
new $_GET['controller']($_GET['param'])

ce qui revient à dire new mesArticles("page3"); et ainsi sans que l'internaute ne sache dans quel dossier se trouve réellement le fichier appeler, tu appel le Bon controller en lui transférant les bonnes informations pour l'affichage demandé.

Mais dans ton cas, ce que tu as besoin c'est que le controller appelé te génère les éléments à insérer dans la vue ...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
$article = new ArticleController();
$listArticle = $article->getList();
 
include "/View/ArticleView.php"; 
// dans ce fichier nous retrouvons la boucle (while/foreach/ ... ) en charge d'afficher les éléments issus de $listArticle

enfin, c'est comme ça que je le vois !... @++

[DrWilly]

Merci pour vos réponses.

metagoto, la solution que tu propose parait vraiment parfaite pour régler le problème de ce modèle. Mais avant de me lancer dans la transformation de mon projet, peut-tu développer les réserves que tu a émise ? Point de vue sécurité par exemple.

Est-ce un modèle que tu me conseil malgré tout, sachant que je cherche quelque chose de simple / souple / non orienté objet / sans page de structure centrale tel que index.php?page=* ?

nours312, comme précisé, je garde l'orienté objet pour mes projets business que je développe en JEE. Pour PHP je me contente d'application simple qui ne justifie pas vraiment cet apport.

Merci.

[metagoto]

Mais avant de me lancer dans la transformation de mon projet, peut-tu développer les réserves que tu a émise ? Point de vue sécurité par exemple.

Vraiment rien de spécial. Il ne s'agit que de trucs élémentaires:

- échapper les données selon le contexte. Genre utiliser htmlspecialchars() dès que tu fais un équivalent de echo pour du html. Corriger vueFormulaire.inc.php etc

- filtrer/controller toutes les données entrées. Par exemple il n'y a pas de précautions pour $lang, $_SERVER['PHP_SELF'] et d'autres.

- éliminer la montage de warnings que php génère potentiellement quand tu accèdes à tous tes indexes d'array (en lecture ou écriture). Utiliser isset(), array_key_exists() au préalable avant de bidouiller avec les arrays (vallable pour $_GET et $_POST aussi)

Il doit y avoir de bons tutos sur ce site (developpez) concernants ces précautions basiques. Je t'invite a te documenter.

Est-ce un modèle que tu me conseil malgré tout, sachant que je cherche quelque chose de simple / souple / non orienté objet / sans page de structure centrale tel que index.php?page=* ?

L'essentiel c'est que ça fonctionne et que tu comprennes ce que tu fais, de quoi être en mesure de corriger les trucs, ajouter des fonctionnalités et tout. Vaut mieux un truc simple.

Je ne conseille rien en particulier. Le truc qui me gênerait le plus par rapport à ce model (autre que les points cités au début), c'est l'aspect "code spaghetti" (qui n'a rien à voir avec le fait de ne pas être OOP), notamment les scopes des variables: déclarées dans un fichier, utilisées ailleurs à plusieurs endroit dans d'autres fichiers. Quelque part, ces multiples inclusions de fichiers font office de déclarations et appels de "fonctions". Ca joue trop sur les side effects.