Je me suis lancé dans le développement d'une application MVC en php
pour accélerer mes dev web.
Je vais vous expliquer ma vision de l'appli, ma manière de penser pour
ensuite vous exposer mon problème (oui sinon je posterai pas :)).
url appelée : domaine.com/nomcontroleur/nomaction
controleur frontal : index.php
controleur (appelé par le frontal) : nomcontroleur.class.php
abstract class controleur {
protected $modele;
protected $vue;
public function __construct($db)
{
$this->db = $db;
}
public function getVue()
{
return $this->vue;
}
public function getModele()
{
return $this->modele;
}
abstract function events($args);
}
class events extends controleur {
private $result;
public function __construct()
{
$this->result['page'] = 'event-article';
}
public function read($args)
{
$this->eventsDao = new eventsDao($this->db);
$this->result['events'] = $this->eventsDao->getEvents();
$this->modele = $this->result;
$this->vue = 'tpl.events.html';
}
}
Le controleur définit le modèle et la vue. Enfin je charge mes
templates smarty. Aucun problème.
Mais voilà, ma page ([url]http://micromediateam.com/proto/[/url])
contient des éléments récurrents. Exemple : une boite sponsors, une
boite news.
Or, j'ai plus ou moins découpé mes controleurs par rapport aux
métiers :
un controleur news (pour afficher les news, ajouteru une news, etc.).
un controleur events
etc.
Donc finalement, il faudrait que j'appelle plusieurs controleurs pour
une requête donnée.
exemple : domaine.com/events
([url]http://micromediateam.com/proto/event.php[/url])
doit appelé le controleur events, le controleur head sponsor, le
controleur sponsors, supporters, etc.
Ma première idée fût de rajouter dans chacun de mes controleurs
l'accès aux données des modules demandées. Mais du coup, mes
contrôleurs n'ont plus vraiment de sens. On retombe sur une page => un
controleur qui appelle les modèles.
Comment procéder ?
Faut-il que selon l'url demandée (events/read), je traite cette
chaine. Dans, un fichier externe je stocke les rubriques à afficher
pour chacune des pages. Et j'appelle en conséquence les controleurs ?
Exemple (très simpliste) :
$events = array('hsponsors', 'sponsor', 'supporter');
foreach($events as $controleur)
{
$c = new $controleur();
}
Enfin, par extension, des modules comme l'identification, gestion d'un
panier doivent-ils être gérés par un controleur spécifique ?
J'ai besoin d'y voir plus clair !
Merci d'avoir lu mon problème d'une limpidité digne de la mer
méditérannée.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
David JOURAND
Bonjour,
Le Fri, 13 Oct 2006 09:27:35 +0000, iD.NicKy a écrit :
Je me suis lancé dans le développement d'une application MVC en php pour accélerer mes dev web.
C'est marrant, j'étais justement en train de remettre à plat le mini framework MVC que j'ai développé pour ma précédente application...
url appelée : domaine.com/nomcontroleur/nomaction
Classique, mais qui nuit généralement à la lisibilité des URLs.
controleur frontal : index.php
Donc MVC2.
Le controleur définit le modèle et la vue. Enfin je charge mes templates smarty. Aucun problème.
Encore cette horreur de Smarty...
Mais voilà, ma page ([url]http://micromediateam.com/proto/[/url]) contient des éléments récurrents. Exemple : une boite sponsors, une boite news.
Il faut mettre en place un mécanisme de décoration ou de composition de page.
Donc finalement, il faudrait que j'appelle plusieurs controleurs pour une requête donnée. exemple : domaine.com/events ([url]http://micromediateam.com/proto/event.php[/url]) doit appelé le controleur events, le controleur head sponsor, le controleur sponsors, supporters, etc.
Vous pouvez utiliser des intercepteurs qui vont ajouter des informations au modèle principal. Ces intercepteurs sont déclaré dans la configuration de l'URL.
Comment procéder ? Faut-il que selon l'url demandée (events/read), je traite cette chaine.
Oui.
Dans, un fichier externe je stocke les rubriques à afficher pour chacune des pages. Et j'appelle en conséquence les controleurs ?
Oui.
Enfin, par extension, des modules comme l'identification, gestion d'un panier doivent-ils être gérés par un controleur spécifique ?
Oui.
Le principe que j'ai adopté et qui s'inspire (fortement) de SpringFramework est le suivant :
Le FrontController fait les tâches suivantes (entre autres) :
1 - Chargement de la configuration liée à cette URL. Cette configuration done le controleur et les intercepteurs.
2 - Appel de la fonction preHandle sur chacun des intercepteurs.
3 - Appel de la fonction handleRequest du controleur. Cette fonction renvoi le model et le nom de la vue.
4 - Appel de la fonction postHandle sur chacun des intercepteurs.
5 - resolution de la vue à partir de son nom.
6 - Appel de la fonction render de la vue. Génère le code HTML.
7 - Appel de la fonction afterCompletion sur chacun des intercepteurs.
-- David JOURAND - http://www.numabilis.com Supprimer "site." et ".invalid" de mon adresse mail pour me répondre.
Bonjour,
Le Fri, 13 Oct 2006 09:27:35 +0000, iD.NicKy a écrit :
Je me suis lancé dans le développement d'une application MVC en php pour
accélerer mes dev web.
C'est marrant, j'étais justement en train de remettre à plat le mini
framework MVC que j'ai développé pour ma précédente application...
url appelée : domaine.com/nomcontroleur/nomaction
Classique, mais qui nuit généralement à la lisibilité des URLs.
controleur frontal : index.php
Donc MVC2.
Le controleur définit le modèle et la vue. Enfin je charge mes
templates smarty. Aucun problème.
Encore cette horreur de Smarty...
Mais voilà, ma page ([url]http://micromediateam.com/proto/[/url])
contient des éléments récurrents. Exemple : une boite sponsors, une
boite news.
Il faut mettre en place un mécanisme de décoration ou de composition de
page.
Donc finalement, il faudrait que j'appelle plusieurs controleurs pour
une requête donnée.
exemple : domaine.com/events
([url]http://micromediateam.com/proto/event.php[/url]) doit appelé le
controleur events, le controleur head sponsor, le controleur sponsors,
supporters, etc.
Vous pouvez utiliser des intercepteurs qui vont ajouter des informations
au modèle principal. Ces intercepteurs sont déclaré dans la
configuration de l'URL.
Comment procéder ?
Faut-il que selon l'url demandée (events/read), je traite cette chaine.
Oui.
Dans, un fichier externe je stocke les rubriques à afficher pour
chacune des pages. Et j'appelle en conséquence les controleurs ?
Oui.
Enfin, par extension, des modules comme l'identification, gestion d'un
panier doivent-ils être gérés par un controleur spécifique ?
Oui.
Le principe que j'ai adopté et qui s'inspire (fortement) de
SpringFramework est le suivant :
Le FrontController fait les tâches suivantes (entre autres) :
1 - Chargement de la configuration liée à cette URL.
Cette configuration done le controleur et les intercepteurs.
2 - Appel de la fonction preHandle sur chacun des intercepteurs.
3 - Appel de la fonction handleRequest du controleur.
Cette fonction renvoi le model et le nom de la vue.
4 - Appel de la fonction postHandle sur chacun des intercepteurs.
5 - resolution de la vue à partir de son nom.
6 - Appel de la fonction render de la vue.
Génère le code HTML.
7 - Appel de la fonction afterCompletion sur chacun des intercepteurs.
--
David JOURAND - http://www.numabilis.com
Supprimer "site." et ".invalid" de mon adresse mail pour me répondre.
Le Fri, 13 Oct 2006 09:27:35 +0000, iD.NicKy a écrit :
Je me suis lancé dans le développement d'une application MVC en php pour accélerer mes dev web.
C'est marrant, j'étais justement en train de remettre à plat le mini framework MVC que j'ai développé pour ma précédente application...
url appelée : domaine.com/nomcontroleur/nomaction
Classique, mais qui nuit généralement à la lisibilité des URLs.
controleur frontal : index.php
Donc MVC2.
Le controleur définit le modèle et la vue. Enfin je charge mes templates smarty. Aucun problème.
Encore cette horreur de Smarty...
Mais voilà, ma page ([url]http://micromediateam.com/proto/[/url]) contient des éléments récurrents. Exemple : une boite sponsors, une boite news.
Il faut mettre en place un mécanisme de décoration ou de composition de page.
Donc finalement, il faudrait que j'appelle plusieurs controleurs pour une requête donnée. exemple : domaine.com/events ([url]http://micromediateam.com/proto/event.php[/url]) doit appelé le controleur events, le controleur head sponsor, le controleur sponsors, supporters, etc.
Vous pouvez utiliser des intercepteurs qui vont ajouter des informations au modèle principal. Ces intercepteurs sont déclaré dans la configuration de l'URL.
Comment procéder ? Faut-il que selon l'url demandée (events/read), je traite cette chaine.
Oui.
Dans, un fichier externe je stocke les rubriques à afficher pour chacune des pages. Et j'appelle en conséquence les controleurs ?
Oui.
Enfin, par extension, des modules comme l'identification, gestion d'un panier doivent-ils être gérés par un controleur spécifique ?
Oui.
Le principe que j'ai adopté et qui s'inspire (fortement) de SpringFramework est le suivant :
Le FrontController fait les tâches suivantes (entre autres) :
1 - Chargement de la configuration liée à cette URL. Cette configuration done le controleur et les intercepteurs.
2 - Appel de la fonction preHandle sur chacun des intercepteurs.
3 - Appel de la fonction handleRequest du controleur. Cette fonction renvoi le model et le nom de la vue.
4 - Appel de la fonction postHandle sur chacun des intercepteurs.
5 - resolution de la vue à partir de son nom.
6 - Appel de la fonction render de la vue. Génère le code HTML.
7 - Appel de la fonction afterCompletion sur chacun des intercepteurs.
-- David JOURAND - http://www.numabilis.com Supprimer "site." et ".invalid" de mon adresse mail pour me répondre.
iD.NicKy
Qu'est qu'un intercepteur ? Selection des controleurs : J'ai pensé à utiliser un fichier xml que je pourrai formater de cette manière <page nom="nompage"> <title></title> <meta></meta> <modules> <module>events</module> <module>sponsors</module> </modules> </page>
Mes controleurs abstract class controleur class news extends controleur class events extends controleur class sponsors extends controleur
Mon shéma est-il applicable et pertinent à votre avis ?
Qu'est qu'un intercepteur ?
Selection des controleurs : J'ai pensé à utiliser un fichier xml que
je pourrai formater de cette manière
<page nom="nompage">
<title></title>
<meta></meta>
<modules>
<module>events</module>
<module>sponsors</module>
</modules>
</page>
Mes controleurs
abstract class controleur
class news extends controleur
class events extends controleur
class sponsors extends controleur
Mon shéma est-il applicable et pertinent à votre avis ?
Qu'est qu'un intercepteur ? Selection des controleurs : J'ai pensé à utiliser un fichier xml que je pourrai formater de cette manière <page nom="nompage"> <title></title> <meta></meta> <modules> <module>events</module> <module>sponsors</module> </modules> </page>
Mes controleurs abstract class controleur class news extends controleur class events extends controleur class sponsors extends controleur
Mon shéma est-il applicable et pertinent à votre avis ?
David JOURAND
Le Sat, 14 Oct 2006 08:07:54 +0000, a écrit :
Qu'est qu'un intercepteur ?
C'est généralement une classe (mais ce n'est pas obligatoire) implémentant des méthodes définies (interface) qui sont appellées avant et après le controleur et qui peuvent modifier l'exécution du flux de controle. Par exemple un intercepteur peut vérifier si l'utilisateur est identifié et rediriger le flux vers un autre controleur (d'identification) si tel n'est pas le cas.
Selection des controleurs : J'ai pensé à utiliser un fichier xml que je pourrai formater de cette manière <page nom="nompage"> <title></title> <meta></meta> <modules> <module>events</module> <module>sponsors</module> </modules> </page>
Trois réflexions : - Pourquoi du XML ? PHP ne convient-il pas ? - Ce fichier mélange présentation (title et meta) et configuration du flux de controle (modules). - UN fichier XML ? Voulez-vous dire UN par page ou UN pour toute l'appli ?
Mes controleurs abstract class controleur class news extends controleur class events extends controleur class sponsors extends controleur
Rien a dire, sauf peut-être que le controleur de base n'a peut-être pas besoin d'être abstrait.
Mon shéma est-il applicable et pertinent à votre avis ?
Votre schéma est applicable. Est-il pertinent ? Il faudrait creuser un peu plus, pour pouvoir le dire.
-- David JOURAND - http://www.numabilis.com Supprimer "site." et ".invalid" de mon adresse mail pour me répondre.
Le Sat, 14 Oct 2006 08:07:54 +0000, iD.NicKy@gmail.com a écrit :
Qu'est qu'un intercepteur ?
C'est généralement une classe (mais ce n'est pas obligatoire)
implémentant des méthodes définies (interface) qui sont appellées avant
et après le controleur et qui peuvent modifier l'exécution du flux de
controle. Par exemple un intercepteur peut vérifier si l'utilisateur est
identifié et rediriger le flux vers un autre controleur
(d'identification) si tel n'est pas le cas.
Selection des controleurs : J'ai pensé à utiliser un fichier xml que
je pourrai formater de cette manière <page nom="nompage">
<title></title>
<meta></meta>
<modules>
<module>events</module>
<module>sponsors</module>
</modules>
</page>
Trois réflexions :
- Pourquoi du XML ? PHP ne convient-il pas ?
- Ce fichier mélange présentation (title et meta) et
configuration du flux de controle (modules).
- UN fichier XML ? Voulez-vous dire UN par page ou UN pour toute l'appli ?
Mes controleurs
abstract class controleur
class news extends controleur
class events extends controleur
class sponsors extends controleur
Rien a dire, sauf peut-être que le controleur de base n'a peut-être pas
besoin d'être abstrait.
Mon shéma est-il applicable et pertinent à votre avis ?
Votre schéma est applicable. Est-il pertinent ? Il faudrait creuser un
peu plus, pour pouvoir le dire.
--
David JOURAND - http://www.numabilis.com
Supprimer "site." et ".invalid" de mon adresse mail pour me répondre.
C'est généralement une classe (mais ce n'est pas obligatoire) implémentant des méthodes définies (interface) qui sont appellées avant et après le controleur et qui peuvent modifier l'exécution du flux de controle. Par exemple un intercepteur peut vérifier si l'utilisateur est identifié et rediriger le flux vers un autre controleur (d'identification) si tel n'est pas le cas.
Selection des controleurs : J'ai pensé à utiliser un fichier xml que je pourrai formater de cette manière <page nom="nompage"> <title></title> <meta></meta> <modules> <module>events</module> <module>sponsors</module> </modules> </page>
Trois réflexions : - Pourquoi du XML ? PHP ne convient-il pas ? - Ce fichier mélange présentation (title et meta) et configuration du flux de controle (modules). - UN fichier XML ? Voulez-vous dire UN par page ou UN pour toute l'appli ?
Mes controleurs abstract class controleur class news extends controleur class events extends controleur class sponsors extends controleur
Rien a dire, sauf peut-être que le controleur de base n'a peut-être pas besoin d'être abstrait.
Mon shéma est-il applicable et pertinent à votre avis ?
Votre schéma est applicable. Est-il pertinent ? Il faudrait creuser un peu plus, pour pouvoir le dire.
-- David JOURAND - http://www.numabilis.com Supprimer "site." et ".invalid" de mon adresse mail pour me répondre.
iD.NicKy
- Pourquoi du XML ? PHP ne convient-il pas ? Cela me semblait "lourd" de créer x tableaux à 2 dimensions :
$pages['news']['title']; etc. Alors qu'un fichier xml est, de mon point de vue, plus clair et plus pratique.
- Ce fichier mélange présentation (title et meta) et configuration du flux de controle (modules). alors 2 fichiers xml mais bon..
- UN fichier XML ? Voulez-vous dire UN par page ou UN pour toute l'appli ? un pour toutes l'appli qui regroupe les données pour toutes les pages
sur l'appel de /events/ => je sélectionne l'item page avec l'attribut events sur l'appel de / => je sélectionne l'item page avec l'attribut index etc.
David JOURAND
Le Sat, 14 Oct 2006 19:06:56 +0000, a écrit :
- Pourquoi du XML ? PHP ne convient-il pas ? Cela me semblait "lourd" de créer x tableaux à 2 dimensions :
$pages['news']['title']; etc. Alors qu'un fichier xml est, de mon point de vue, plus clair et plus pratique.
Plus clair, sans aucun doute. Plas pratique, peut-être. Plus efficace, je ne pense pas. Ce n'est pas le fichier XML en lui même qui pose problème, mais toute la machinerie que vous allez mettre en place pour le traiter...
- Ce fichier mélange présentation (title et meta) et configuration du flux de controle (modules). alors 2 fichiers xml mais bon..
Pour moi ce fichier est un fichier de configuration du flux de controle. Par conséquent title et meta n'ont rien à faire ici. Vous pouvez les placer dans le modèle ou dans la vue selon votre modélisation. Globalement, et pour schématiser, vous devriez avoir un fichier pour le modèle, un fichier pour l'accès aux données, un fichier pour le controleur, un fichier pour la vue et ce dernier fichier de configuration...
- UN fichier XML ? Voulez-vous dire UN par page ou UN pour toute l'appli ? un pour toutes l'appli qui regroupe les données pour toutes les pages
(après réflexion/test/codage) :
[snip]
Si vous n'avez pas trop de pages, cela peut être jouable, mais traiter le fichier complet à chaque requête HHTP peut être rapidement lourd...
sur l'appel de /events/ => je sélectionne l'item page avec l'attribut events sur l'appel de / => je sélectionne l'item page avec l'attribut index etc.
Vous pourriez faire un fichier /conf/events.php inclus par le controlleur frontal :
$controleur = new EventController(); $controleur->setAction($action); // $action = newsList par exemple. $decorators = array(new RosterDecorator(), new TotoDecorator()); // eventuellement : $controleur->setTitle($title); ...
Et dans index.php (front controller) :
$controleur->handleRequest($request); foreach($decorators as $decorator) { $decorator->decorate(); }
Voila l'idée...
-- David JOURAND - http://www.numabilis.com Supprimer "site." et ".invalid" de mon adresse mail pour me répondre.
Le Sat, 14 Oct 2006 19:06:56 +0000, iD.NicKy@gmail.com a écrit :
- Pourquoi du XML ? PHP ne convient-il pas ?
Cela me semblait "lourd" de créer x tableaux à 2 dimensions :
$pages['news']['title'];
etc.
Alors qu'un fichier xml est, de mon point de vue, plus clair et plus
pratique.
Plus clair, sans aucun doute. Plas pratique, peut-être. Plus efficace,
je ne pense pas. Ce n'est pas le fichier XML en lui même qui pose
problème, mais toute la machinerie que vous allez mettre en place pour le
traiter...
- Ce fichier mélange présentation (title et meta) et configuration du
flux de controle (modules).
alors 2 fichiers xml mais bon..
Pour moi ce fichier est un fichier de configuration du flux de controle.
Par conséquent title et meta n'ont rien à faire ici. Vous pouvez les
placer dans le modèle ou dans la vue selon votre modélisation.
Globalement, et pour schématiser, vous devriez avoir un fichier pour le
modèle, un fichier pour l'accès aux données, un fichier pour le
controleur, un fichier pour la vue et ce dernier fichier de configuration...
- UN fichier XML ? Voulez-vous dire UN par page ou UN pour toute
l'appli ?
un pour toutes l'appli qui regroupe les données pour toutes les pages
(après réflexion/test/codage) :
[snip]
Si vous n'avez pas trop de pages, cela peut être jouable, mais traiter le
fichier complet à chaque requête HHTP peut être rapidement lourd...
sur l'appel de /events/ => je sélectionne l'item page avec l'attribut
events
sur l'appel de / => je sélectionne l'item page avec l'attribut index
etc.
Vous pourriez faire un fichier /conf/events.php inclus par le controlleur
frontal :
$controleur = new EventController();
$controleur->setAction($action); // $action = newsList par exemple.
$decorators = array(new RosterDecorator(), new TotoDecorator());
// eventuellement :
$controleur->setTitle($title); ...
Et dans index.php (front controller) :
$controleur->handleRequest($request);
foreach($decorators as $decorator) {
$decorator->decorate();
}
Voila l'idée...
--
David JOURAND - http://www.numabilis.com
Supprimer "site." et ".invalid" de mon adresse mail pour me répondre.
- Pourquoi du XML ? PHP ne convient-il pas ? Cela me semblait "lourd" de créer x tableaux à 2 dimensions :
$pages['news']['title']; etc. Alors qu'un fichier xml est, de mon point de vue, plus clair et plus pratique.
Plus clair, sans aucun doute. Plas pratique, peut-être. Plus efficace, je ne pense pas. Ce n'est pas le fichier XML en lui même qui pose problème, mais toute la machinerie que vous allez mettre en place pour le traiter...
- Ce fichier mélange présentation (title et meta) et configuration du flux de controle (modules). alors 2 fichiers xml mais bon..
Pour moi ce fichier est un fichier de configuration du flux de controle. Par conséquent title et meta n'ont rien à faire ici. Vous pouvez les placer dans le modèle ou dans la vue selon votre modélisation. Globalement, et pour schématiser, vous devriez avoir un fichier pour le modèle, un fichier pour l'accès aux données, un fichier pour le controleur, un fichier pour la vue et ce dernier fichier de configuration...
- UN fichier XML ? Voulez-vous dire UN par page ou UN pour toute l'appli ? un pour toutes l'appli qui regroupe les données pour toutes les pages
(après réflexion/test/codage) :
[snip]
Si vous n'avez pas trop de pages, cela peut être jouable, mais traiter le fichier complet à chaque requête HHTP peut être rapidement lourd...
sur l'appel de /events/ => je sélectionne l'item page avec l'attribut events sur l'appel de / => je sélectionne l'item page avec l'attribut index etc.
Vous pourriez faire un fichier /conf/events.php inclus par le controlleur frontal :
$controleur = new EventController(); $controleur->setAction($action); // $action = newsList par exemple. $decorators = array(new RosterDecorator(), new TotoDecorator()); // eventuellement : $controleur->setTitle($title); ...
Et dans index.php (front controller) :
$controleur->handleRequest($request); foreach($decorators as $decorator) { $decorator->decorate(); }
Voila l'idée...
-- David JOURAND - http://www.numabilis.com Supprimer "site." et ".invalid" de mon adresse mail pour me répondre.
