Modele MVC : Question concernant le choix des controleurs

WRInaute accro
Salut

J'ai des doutes concernant mes choix sur les contrôleurs de mon mini framework personnel.

Prenons un site (un peu construit comme WRI, a titre d’exemple) qui aurait les sections suivantes :

blog → contient plusieurs categories (cat1, cat2, cat3...)
dossiers → contient plusieurs categories (cat1, cat2, cat3...)
annuaire → contient plusieurs categories (cat1, cat2, cat3...)
news

Dans mon MVC j'aurais tendance à créer 4 contrôleurs

Code:
class ControleurBlog extends controleur {

	public function index() {}	
	public function categorie() {}
	public function post() {}
}

class ControleurDossiers extends controleur  {

	public function index() {}	
	public function categorie() {}
	public function post() {}
}

class ControleurAnnuaire extends controleur {

	public function index() {}	
	public function categorie() {}
	public function post() {}
}

class ControleurNews extends controleur {

	public function index() {}	
	public function post() {}
}

Avec ce schéma je me retrouve avec des URL qui n'ont pas besoin de routing, juste mon contrôleur frontal qui dirige bien vers le bon contrôleur et la bonne action.

je pourrais avoir des url de la sorte, sans que ça soit gênant :

site.ndd/blog/index
site.ndd/blog/categorie/cat1
site.ndd/blog/categorie/cat1/2 <--- pour la page 2
site.ndd/blog/post/slug/id

les paramètres passés aux actions sont vérifiés dans chaque contrôleur. Et si nécessaire je fais des 301

Alors a priori ce schéma semble pas trop mauvais MAIS voilà avec un tel schéma je me retrouve pour le moment avec pas mal de traitement identiques dans ces contrôleurs.
Pas mal de similitude dans le traitement situé dans les méthodes qui ont le même nom.

Si je prend par exemple la méthode categorie, elle fera appel quasiment aux mêmes modèles et fera quasiment le même traitement, a quelques petits paramétrages prêt, quelque soit le contrôleur.
(Certes je suis quand même libre de traiter totalement différemment du jour au lendemain une des sections avec cette méthode.)

Pour palier à ce problème de redondance je met dans des fichiers à inclure (de façon pas très propre) les bouts de traitement identiques

exemple :

Code:
public function categorie()
    {        
        
        /**** Configuration du traitement ****/
        
	//ici j'initialise quelques variables par rapport au besoin du controleur en question
	$nbArtParPage = 20 ;
	etc.

        /**** On inclu le traitement ****/
	//lignes de traitement identiques utilisé par chaque controleur faisant appel a la méthode 	categorie

        require(CHEMIN_INTER."include/traitCategorie.php");          
        
        /**** On génère la vue ****/ 
	//ici j'appelle la methode genererVue de Controleur qui appelle la la vue situté dans vue/nomcontroleur/categorie.php

        $this->genererVue("categorie", $d); 
    }

Je trouve donc cet appel pas très propre  : require(CHEMIN_INTER."include/traitCategorie.php");

d'autant plus qu'il s'agit d'un appel d'une page PHP qui n’est ni une fonction, ni une classe, mais simplement des lignes de codes php (appel aux méthodes des modèles etc.).

Si on regarde CackePHP il semblerait que le schéma à appliquer serait plutôt le suivant :

Code:
class ControleurArticles  {

	public function index() {}	
	public function categorie() {}
	public function post() {}
}

Articles = (de préférence) le nom de la table dans la BDD, sachant que tous les articles du blog, des dossiers, de l'annuaire ou des news seraient dans la table articles.

Mais j'ai plusieurs problèmes avec le schéma de CakePhP:

1) sans routing on aurait surement des url plutôt moches comme :

site.ndd/articles/index/blog
site.ndd/articles/categorie/blog/cat1
etc.
Avec cette solution a mon avis il faudrait ajouter en paramètre supplémentaire: la section (ici blog, dossiers etc.).

Et là a priori le routing s'impose (et je suis pas a l'aise avec ca)

2) Quoi qu'il en soit avec cette solution comment arriver avec un seul contrôleur a bien différencier les sections blog, dossiers etc. car même si une bonne partie du traitement dans chaque méthode serait identique, les vues et les informations a afficher ne sont pas forcément toujours les mêmes (qu'il s'agisse du menu, du nombre d'articles a afficher, etc.). je pourrais également vouloir faire un traitement très spécifique pour une des sections...

Alors je me sens plus à l'aise avec la 1ere solution, mais ça ne semble pas être un MVC très propre.

Qu'en pensez vous ?
 
WRInaute discret
Salut,

p'tite précision:
Il n'y a aucun incidence de l’architecture de développement MCV, ou un autre modèle de programmation, et le format des URL
Le format des URL est définit par l'URL Rewriting,
par ex
RewriteRule ^site.ndd/blog/categorie/cat1$ /front_controller.php?menu1=blog&menu2=categorie&menu3=cat1[L]
L'internaute saisie site.ndd/blog/categorie/cat1 et ton générateur de page front_controller.php sera appelé avec les différents paramètres.

La première solution est proche à du PHP procédurale (php3), la solution cakePHP est probablement du php5 basé sur les class.

As-tu une doc sur l'utilisation de PHP5 et le modele MCV ?
 
WRInaute occasionnel
pas mal de traitement identiques dans ces contrôleurs...
Pour palier à ce problème de redondance je met dans des fichiers à inclure
La prog orientée objet ne te permet pas d'éviter ça ? Si les contrôleurs sont les enfants d'un contrôleur général, pourquoi ne pas utiliser des méthodes du contrôleur général dans les contrôleurs enfants ?

Code:
class PostsController extends Controller

Pour le routing, c'est les expressions régulières le problème ?
Dernièrement j'ai lu ça, et je ne regrette pas :)
http://www.eyrolles.com/Informatique/Livre/les-expressions-regulieres- ... 2914010658
 
WRInaute accro
@Fobec.com : je fais bien la redirection indiquée dans mon .htaccess étant donné que j'ai le contrôleur frontal.
Pour ça il n'y a aucun soucis.

Code:
RewriteRule ^([a-zA-Z0-9\-_]*)/?([a-zA-Z0-9\-_]*)?/?([a-zA-Z0-9\-_]*)?/?([a-zA-Z0-9\-_]*)?/?([a-zA-Z0-9\-_]*)?/?$ index.php?controleur=$1&action=$2&param1=$3&param2=$4&param3=$5 [NC,L]

J'ai des class modèles : ArticlesManager, MembresManager etc.
Je fais de l'autoload pour l'appel des class

Mais un des problèmes dans mon MVC semble venir du choix des contrôleurs, ce qui a forcément une incidence sur les URL et sur la redondance du code (ce qui n’est pas compatible avec le modele MVC). Et la effectivement je pense que je réfléchis un peu trop en procédural.

Avec la solution 2 étant donné que je dois bien indiquer le contrôleur, l'action et la section où je suis on a forcément ceci :

site.ndd/articles/index/blog (controleur/action/module)

on peut évidemment mettre dans l'ordre qu'on veut mais ça ne change rien au problème :

site.ndd/blog/articles/index (module/controleur/action)

dans ma solution 1, indiqué la section (module) est inutile étant donné qu'il s'agit du nom du contrôleur, donc je réduis de façon importante la taille de mon URL.

Mais pour appliquer la solution 2 et si je veux réduire la taille de l'URL il me semble que c'est le routing/dispatcher qui peut s'en charger
Et je n'arrive, de toute façon, vraiment pas à voir comment avec un seul contrôleur "articles" je pourrais gérer l'ensemble des sections (blog, dossiers etc.) et pouvoir être libre de traiter ces sections différemment. Difficile de se séparer du procédural quand on a fait que ça.

Mais suis-je dans le vrai concernant la 2eme solution? Faut-il normalement un seul contrôleur Articles pour gérer tous ce qui concerne les articles qu'ils soient du blog, annuaires, dossiers, news etc.) ?

Code:
class ControleurArticles  {

   public function index() {}   
   public function categorie() {}
   public function post() {}
}

car si c’est le cas je vois vraiment pas comment faire :/

Pour la doc, j'ai des bouquins sur le PHP5 et la POO, je regarde également sur le net. J'ai également une formation en inforamtique mais j'ai plus pratiqué réellement depuis des années :)
Pour le modèle MVC je n'ai vu aucun bouquin (pas certain qu'il y en ai) et les seuls docs sur le net sont basés sur des exemples limités et toujours les mêmes :

sur developpez.com
sur openclassroom.com
sur grafikart.com
etc.

J'ai également regardé un peu du côté de la doc de cakePHP, mais je suis aps plus avancé .

Généralement on voix des exemple de controleur du type :

Code:
class ControleurPosts  {
   public function index() {}   
   public function categorie() {}
   public function view() {}
}

Qui fait appel a un model du genre

Code:
class Post  {
   public function select() {}   
   public function update() {}
   public function delete() {}
   public function insert() {}
}

Et les urls dans les exemples sont souvent de ce type :

site.ndd/posts/index
site.ndd/posts/view/id

et le .htaccess suivant :

Code:
RewriteRule ^([a-zA-Z0-9\-_]*)/?([a-zA-Z0-9\-_]*)?/?([a-zA-Z0-9\-_]*)?/?([a-zA-Z0-9\-_]*)?/?([a-zA-Z0-9\-_]*)?/?$ index.php?controleur=$1&action=$2&param1=$3&param2=$4&param3=$5 [NC,L]

Mais difficile ensuite de transposer ces exemples dans un site concret
Comment avec cette class controleurPosts et cet url_rewriing pouvoir obtenir des URl de ce type :

site.ndd/blog/index
site.ndd/blog/categorie/cat1
site.ndd/blog/categorie/cat1/2 <--- pour la page 2
site.ndd/blog/post/slug/id
site.ndd/dossiers/index
site.ndd/dossiers/categorie/cat1
site.ndd/dossiers/categorie/cat1/2 <--- pour la page 2
site.ndd/dossiers/post/slug/id

et que toutes ces url appellent bien le controleur controleurPosts (controleurArticles si on reprend l'exmeple du début de ce topic)
 
WRInaute accro
@Doubrovski ; alors effectivement c'est une solution qui m'a traversé l'esprit.
Mettre des methodes : index, categorie et article dans le controlleur parent "Controleur"
Ce qui resterait dans l'esprit de la POO et éviterait cette include "procédural" pas très clean.

Après faudrait encore que je vois pour passer les differents paramètres de configurations a ces methodes. peut être utiliser une variable protected $configuration= array()
dans ma class Contrôleur et passer dans ce tableau tous les paramètres de configuration qui sont propres a chaque controleur

je vais peut être me pencher sur cette idée.

D'ailleurs je sais meme pas si je vais pas créer une couche supplémentaire d'hériatge :

Code:
class ControleurBlog extends controleurArticles {

   public function index() {}   
   public function categorie() {}
   public function post() {}
}

Code:
class ControleurArticles extends controleur {

  protected $configuration = array () ; 

   protected function indexArt() {}   
   protectedc function categorieArt() {}
   protectedc function postArt() {}

}

et de cette facon mais autres class controleur (membres, etc.) ne hargeraient pas de méthodes inutiles

Code:
class ControleurMembres extends Controleur {

   public function profil() {}   
   etc.
}

A priori ca semblerait un poil plus propre, et je pense qu'on a bien de la POO et le modèle MVC serait respecté (enfin je pense.
 
WRInaute discret
si j'ai bien compris,
-> il y a 1 controler par catégorie du site, transmis dans le .htacces
index.php?controleur=$1&action=$2&param1=$3&param2=$4&param3=$5 [NC,L]
-> un seul php front pour l'ensemble du site: index.php,
Le controler est construit pour une catégorie du site.

une autre architecture possible (celle que j'utilise):
- 1 front par catégorie (blog, dossiers, ...),
- 1 controler par type de page à générer (article, liste d'article, index, mobile) ou par type d'action (GET, ajax, POST, ...)
- 1 view par type de page liée à un fichier template.

Les controler sont moins nombreux, plus générique et il n'y a pas de redondance de code. Le script en front sert à adapter le controler à la catégorie ou l'on se trouve.
Il s'agit également d'un MVC, ou le controler est construit autour d'un type de page au lieu liée à une catégorie du site.
Est-ce mieux ou pas, pffff, je trouve cette architecture plus facile à maintenir.
 
WRInaute accro
Ah en effet je n'avais pas imaginé une structure comme celle-ci, a creuser, c’est en effet intéressant également

Après dans mon site j'aurais environ 8 grosses catégories, donc ca ferait tout de même 8 controleurs frontaux et 8 lignes dans le .htaccess. On finirait toujours par se retrouver avec de la redondance. Après en effet reste a savoir quelle solution est la plus facilement modulable et maintenable et qui propose le moins de redondance.

Pourrais tu me montrer tes redirections du .htaccess pour gérer ces différents contrôleur frontaux? :wink:

En tout cas merci a vous vous m'avez été d'une grande aide, j'ai de bonnes alternatives proposées :wink:
 
WRInaute occasionnel
Je ne pense pas qu'il y ait de modèle "parfait" tant qu'on respecte le principe de l'encapsulation et de l'héritage, après chacun son système. Il faut viser la logique et éviter les répétitions du code.

Ça fait longtemps que je ne me suis pas plongé dans le système cakePHP, mais ne comprends pas trop pourquoi le htaccess ne contient pas juste une règle qui redirige tout vers le dispatcher qui découpe l'url ? Les paramètres sont stockés dans un tableau ce qui permet d'en avoir à l'infini.

Le controlleur général dans le tuto grafikart sert à charger les vues. Mais si une action se répète dans les enfants ça me paraît logique de la faire monter d'un grade.
 
WRInaute accro
Oui je pense aussi que le dispatcher et router permettent d'améliorer grandement les choses et pour la solution de fobecv permettrait surement d'éviter d'avoir autant de contrôleurs frontaux et de lignes dans le .htaccess

En ce qui me concerne j'ai encore beaucoup de mal a comprendre le dispatcher et le routing.
Mais j’abandonne pas l'idée de l'intégrer, même si pour le moment je m'en passe très bien :mrgreen:

En tout cas là je viens d'essayer l'héritage d'une classe contrôleur 'controleurArticles' et ça a l'air de très bien fonctionner, ca va m'éviter pas mal de redondance dans mon code et je conserve donc un modèle MVC POO crédible (même si je n'ai pas de routing) :mrgreen:

Mon prochain topic sera surement sur l'optimisation des requêtes SQL (une véritable galçre), mais là c’est une autre histoire.... :oops:
 
WRInaute accro
Vous vous cassez la tête avec le rewrite: 4 exemples différents:
Code:
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d

# $_SERVER['QUERY_STRING']
#RewriteRule ^(.*)$ index.php?/$1 [QSA,L]

# $_SERVER['REQUEST_URI']
#RewriteRule ^(.*)$ index.php [QSA,L]

# $_SERVER['PATH_INFO']
RewriteRule ^(.*)$ index.php/$1 [QSA,L]

# $_GET['url']
#RewriteRule ^(.*)$ index.php?url=/$1 [QSA,L]
Ensuite c'est 1 seul paramètre à "parser":
PHP:
<span class="syntaxdefault"></span><span class="syntaxkeyword"><?</span><span class="syntaxdefault">php<br /></span><span class="syntaxkeyword">list(,</span><span class="syntaxdefault"> $controller</span><span class="syntaxkeyword">,</span><span class="syntaxdefault"> $action</span><span class="syntaxkeyword">,</span><span class="syntaxdefault"> $param1</span><span class="syntaxkeyword">,</span><span class="syntaxdefault"> $param2</span><span class="syntaxkeyword">)</span><span class="syntaxdefault"> </span><span class="syntaxkeyword">=</span><span class="syntaxdefault"> explode</span><span class="syntaxkeyword">(</span><span class="syntaxstring">'/'</span><span class="syntaxkeyword">,</span><span class="syntaxdefault"> $_SERVER</span><span class="syntaxkeyword">[</span><span class="syntaxstring">'PATH_INFO'</span><span class="syntaxkeyword">]);</span><span class="syntaxdefault"> </span>

CakePHP parse le REQUEST_URI: https://github.com/cakephp/cakephp/blob/master/app/webroot/.htaccess

Un bon petit routeur standalone en PHP: https://github.com/dannyvankooten/AltoRouter (REQUEST_URI aussi)

Via l'héritage de classe (+ events), voilà ce que j'avais réussi à faire en CakePHP: https://github.com/spout/cakephp-starter-kit/blob/master/app/Controlle ... roller.php toutes les actions CRUD (+admin) + search + autocomplete + feed + markers + ... sont auto générées dans le AppController.
( https://github.com/FriendsOfCake/crud )
 
WRInaute occasionnel
A mon avis ça te simplifierait la vie, au moins le dispatcher.
Il suffit d'un explode et tu sais que la première valeur est le controlleur, la deuxième l'action, puis les paramètres. Tout ça peut être adapté sans jamais modifier le htaccess (ça peut être différent de controlleur/action/params).

htaccess :
Code:
RewriteEngine on
RewriteRule ^([a-zA-Z0-9\-\_\/]*)$ index.php?p=$1

dispatcher :
Code:
$params = explode('/',$_GET['p']);
$controller = $params[0];
$action = isset($params[1]) ? $params[1] : 'index';
[...etc]

Bon après je sais pas, je ne connais que cakePHP et des variantes. Et pour le routing oui, je me souviens avoir galéré quand même...

edit: j'avais pas vu le msg de spout, c'est ce que je voulais dire, en mieux ^^
 
WRInaute accro
Oui je pourrais simplifier mon .htaccess et utiliser le dispatcher mais je trouvais ça pratique d'avoir directement les différents paramètres bien défini dans le GET. Etant donné qu'il s'agit d'une variable globale ça se transmet plus facilement aux contrôleurs.

Mais je vais essayé de voir si je peux améliorer en faisant de la façon indiquée. Grafikart fait par exemple passé les paramètres récupéré du GET en argument des méthodes des contrôleurs. Je ne sais pas trop quoi penser de cette solution.

Pour le moment je m'étais basé en partie sur le modèle MVC expliqué sur développez.com :

http://bpesquet.developpez.com/tutoriels/php/evoluer-architecture-mvc/

Modèle qui montre vite ses limites (pas de routing non plus, ou du moins très limité)

@spout : merci pour les liens, je te sens très a l'aise avec le modèle MVC, j'aimerais pouvoir l'être également :mrgreen:
pas certain que ça soit aussi évident d'intégrer un module externe de routage.

Pour en revenir aux contrôleurs si on fait un seul contrôleur pour tout ce qui concerne les articles (que ça soit pour le blog, les dossiers, l'annuaire etc. : facon cakePHP je crois) exemple :

Code:
class ControleurPosts  {   

   public function index() {

    1) traitement
    2) appel de la vue

    }   

   public function liste() {

    1) traitement
    2) appel de la vue

    }

   public function post() {

    1) traitement
    2) appel de la vue

   }

}

1) Comment différencier notre module (catégorie) blog, de celui des dossiers, de l'annuaire etc. D'autant plus si la présentation des articles, le nombre d'articles qu'on affiche etc. est différent en fonction du module (blog, dossiers...).

2) Et je n'arrive pas a voir comment gérer cette façon de faire pour avoir ces url :

site.ndd/blog/index
site.ndd/blog/liste/cat1
site.ndd/blog/post/slug/id

ou de préférence :

site.ndd/blog/index
site.ndd/blog/cat1
site.ndd/blog/cat1/idpage
site.ndd/blog/slug/idart

Comment dans ces derniers formats d'url on peut savoir quel contrôleur et quelle action appeler (je me doute que c’est le routeur qui gère ça).
Et comment le routeur peut ne pas s'embrouiller entre ces 2 url:

site.ndd/blog/cat1/idpage
site.ndd/blog/slug/idart

Loin d'être évident de mettre en place une base solide pour son MVC. Et pas si évident que ca (lorsqu'on est habitué a du procédural et qu'on a pas codé depuis longtemps) a se projeter avec un modele MVC oriénté POO
 
WRInaute accro
noren a dit:
1) Comment différencier notre module (catégorie) blog, de celui des dossiers, de l'annuaire etc. D'autant plus si la présentation des articles, le nombre d'articles qu'on affiche etc. est différent en fonction du module (blog, dossiers...).

2) Et je n'arrive pas a voir comment gérer cette façon de faire pour avoir ces url :
L'ordre de la définition des routes, la première qui matche = celle suivie.

noren a dit:
site.ndd/blog/index
site.ndd/blog/liste/cat1
site.ndd/blog/post/slug/id
Différentiables

noren a dit:
site.ndd/blog/index
site.ndd/blog/cat1
site.ndd/blog/cat1/idpage
site.ndd/blog/slug/idart
La dernière il faut quand même un truc pr la différencier, ou alors que les routes "site.ndd/blog/cat1/idpage" soient définies plus explicitement à partir de la DB.

noren a dit:
Loin d'être évident de mettre en place une base solide pour son MVC. Et pas si évident que ca (lorsqu'on est habitué a du procédural et qu'on a pas codé depuis longtemps) a se projeter avec un modele MVC oriénté POO
D'où l'idée d'utiliser des frameworks qui ont fait leurs preuves :D
 
WRInaute accro
oui mais utiliser un framework ne répond pas à toutes les problématiques que l'on peut se poser ;)

Si je prend la question sur le choix du contrôleur et comment différencier le blog/dossiers etc. je me poserais surement la même question avec un framework

utiliser un framework c’est bien, savoir l'utiliser c’est autre chose :mrgreen:
on peut très bien utiliser un framework et mal s'en servir et avoir un site avec une modélisation bancale.

Et la actuellement je n'arrive pas à voir comment même avec un framework on peut différencier nos articles du blog, des dossiers etc, juste avec un controleur (ControleurPosts), et comment on peut personnaliser chacune de nos grosses categories (blog, dossiers..) avec ce même contrôleur.

c’est pour ca que dans mon MVC je suis parti sur des controleurs : controleurBlog, controleurDossiers etc (et que ces controleurs héritent d'une class controleurArticles) . et je pense que je ferais surement la même chose si j’utilisais cakePHP :?
 
WRInaute accro
noren a dit:
Et je n'arrive, de toute façon, vraiment pas à voir comment avec un seul contrôleur "articles" je pourrais gérer l'ensemble des sections (blog, dossiers etc.) et pouvoir être libre de traiter ces sections différemment.
C'est ton modèle qui est bancal (ou compliqué de mon point de vue).

En fait le contrôleur n'a pas a savoir si c'est un blog un dossier ou une page annuaire, et encore moins a savoir ou est cet article (il ne dois pas être dépendant de l'url vis a vis du type d'article). Il est la pour gérer des requêtes qui potentiellement induisent un traitement ou pas (il peut être interessant de conserver des extensions de fichier ou dossier pour justement faire le trie dans le htaccess).

Dans le principe tu as :
* des articles qui sont d'un certains type (billet de blog, page forum, fiche annuaire, article classique, fiche produit e-commerce, ...) > notion de type de page.
* ces articles appartiennent à une section, qui peut être une sous section d'une autre section (récursivité) le tout donnant une url type site.ndd/section/sous-section/article > notion de localisation de l'article qui permet de mettre n'importe quel type de page dans n'importe quelle section (comprendre qu'une section peut contenir des billets et des pages produits pourquoi se limiter).

Partant de là ton contrôleur a en charge d'identifier le type d'article (via l'url (comme dit spout, chez moi c'est le "premier qui match")) d'instancier ta classe article qui est adaptée aux différents types d'articles (puisque c'est là qu'est défini ce type) et d'aiguiller vers la méthode voulue pour générer ta vue au final.

* C'est aussi à ce stade (contrôleur) que tu peux décider de servir une vue en cache ou d'instancier tout le bataclan pour la composer (et éventuellement de la mémoriser dans le cache).
* note aussi au passage que si tu incorpore le NDD a ta classe article et que le contrôleur le prend en compte tu passe multisite au passage :wink:
 
WRInaute accro
Oui je pense aussi que mon MVC est un peu bancal. J'essaye à chaque fois de l’améliorer dès que je constate de la redondance et c'était donc le cas avec mes contrôleurs correspondant a chacune de mes grosses catégorie.

Sur un de mes sites je vais avoir 8 grosses categories (blog etc.), avec mon système, je me retrouverais donc avec 8 contrôleurs comportant tous des methodes index, liste, article. Et évidemment les problèmes sautent aux yeux. C'est franchement pas jojo

Je ne pense pas que ça soit mon MVC qui soit en cause mais uniquement mes choix de contrôleurs et le fait que je n'ai toujours pas mis en place un système de routing qui enfin de compte va s'avérer indispensable.
Il va donc falloir que je réveille quelques neurones pour essayer de comprendre ce fichu routage. (@spout : je préfère mettre en place mon propre routage plutôt qu'utiliser un module externe, c’est pour mon expérience personnelle :wink:, entre autre )

Avec mon système je pouvais très bien avoir des url du type site.ndd/controleur/action/param1 sans qu'il soit nécessaire de mettre un routeur en place. Ce système était pas gênant pour un petit projet mais pour un plus gros projet les faiblesses apparaissent.

dans ma bdd j'ai ce modèle la :

j'ai des categories (sections) : blog, dossiers etc.
et des sous catégories qui appartiennent aux sections (récusrivité)

En gros dans ma table taxon je stocke aussi bien, les catégories, les tags etc. avec un champ parent_id.
et j'ai une table qui fait la relation entre le taxon et le post (article)

si dans la catégorie "dossiers" j'ai une sous catégorie "référencement" (je prend tjrs WRI comme exemple), dans parent_id de l'enregistrement "référencement" j'ai l'id de la catégorie dossiers.
Je fais de la récursivité que sur 2 niveau pour éviter les requêtes qui font exploser la bdd, je galère déjà pas mal avec l'optimisation de mes jointures (surtout quand il y a des conditions, order by etc.) :)

Voir ce post

https://www.webrankinfo.com/forum/t/optimisation-requetes-jointures-index.174080/

J'ai vu il y a pas longtemps la représentation intervallaire (vous l'utilisez? ou vous utilisez le systele de recursivité avec l'id parent?), mais la je me sens franchement pas de changer mon système d'autant plus que je n'envisage pas d'avoir plus de profondeur dans mes catégories.

Donc je pense qu'il y a une bonne distinction entre mes sections et sous sections, ce qui permet normalement de partir sur d'assez bonnes bases pour le MVC.

Donc si j'ai bien compris ce que tu dis , j'ai le contrôleur suivant :

Code:
class ControleurPosts  {   

   public function index() {

    1) traitement
    si section = blog 
        traitement A
    si section = dossiers 
        traitement B
    si section = annuaires
       traitement C

    2) appel de la vue
    si section = blog
        vue A
    si section = dossiers
        vue B
    }   

   public function liste() {

    1) traitement
        pareil
    2) appel de la vue
       pareil
    }

   public function post() {

    1) traitement
        pareil
     
    2) appel de la vue
       pareil
   }

}
pour accéder au controleurPost et a l'action liste je dois a la base avoir une URL comme celle-ci :

site.ndd/posts/liste

Mais pour y arriver avec cette url :

site.ndd/blog/liste

je suis donc obligé de passer par un routeur c'est bien ca? Et il devient donc indispensable avec ce système

J'aurais donc une règle dans mon routeur de ce type :

Router::connect('blog/liste/:slug','posts/liste/slug:([a-z0-9\-]+)') (règle récupéré du tuto de grafikart)

Mais y a un truc qui m'échappe c’est comment le controleurPosts sait que c’est la section blog qu'on demande?
Puisque lui la seule chose qu'il récupère c'est les paramètres suivants :
controleur : posts,
action : liste,
slug:...

puisqu’en gros le routeur transforme blog/view etc en posts/view pour qu'on puisse accéder au bon contrôleur et a la bonne action.
Donc mon contrôleur ne voit a aucun moment le paramètre "blog", non?. A h moins qu'il voit contrôleur=blog ?

je sais pas si je suis très clair :mrgreen:

Va falloir que je regarde à nouveau le tuto de grafikart :)
Ca commence a s’éclaircir, mais il y a toujours des zones d'ombres.

mais quoi qu'il en soit en fin de compte dans mon controleurPosts je me retrouve a faire de très nombreuses vérfications pour déterminer la section demandé et et effectuer beaucoup de traitements ?
Comme indiqué si dans un de mes projets j'ai 8 grosses sections (blog etc.) controleurPosts peut vite devenir complexe (enfin je crois). je n'arrive pas encore a me projeter et a imaginer ce que ca donnera au niveau du traitement avec un seul contrôleur.

Pour les vues je pourrais pas éviter d'en avoir beaucoup?

vue/blog/index.php
vue/blog/liste.php
vue/blog/post.php
vue/dossiers/index.php
vue/dossiers/liste.php
vue/dossiers/post.php
etc.

A moins d'avoir

vue/posts/index.php
vue/posts/liste.php
vue/posts/post.php

mais dans ce cas ça signifie que dans chaque vue j'ai beaucoup de conditions etc. surtout si je veux représenter vraiment différemment mes vues en fonction de la catégorie (section)

résultat j'aurais pas forcément un code lisible et forcément facile a maintenir si j'ai un contrôleur et une vue avec beaucoup de lignes de codes.
 
WRInaute accro
bon j'avais une lueur d'espoir en regardant le code source du tuto de grafikart, mais il y a effectivement le probleme que j'indique plus haut.

même avec une règle de routage comme celle-ci :

Router::connect('blog/category/:slug','posts/category/slug:([a-z0-9\-]+)');

lorsqu'on est dans notre contrôleur Posts, on n'a aucun moyen de savoir qu'on est dans la section "blog", la seule chose que voix le contrôleur c'est :

controleur = posts
action = category
slug = le slug

Donc si dans ce contrôleur on veut faire des traitements spécifiques en fonction de la section demandée, je ne vois pas trop comment faire.

J'ai essayé d'appliquer ce genre de règle :

Router::connect(':module/category/:slug','posts/category/module:([a-z0-9\-]+)/slug:([a-z0-9\-]+)');

mais ça ne marche pas :/
 
WRInaute accro
Bon j'ai regardé le code de grafikart qui propose un routeur

en ajoutant une règle comme celle ci je récupère le module (section) , ce qui permet dans le controleur d efaire le traitement adequat j'imagine

Router::connect(':module/liste/:slug','posts/liste/module:([a-z0-9\-]+)/slug:([a-z0-9\-]+)')

Faut donc que je regarde ne détail le fonctionnement de son routeur

maintenant reste à voir comment traiter la requête en fonction du module dans un seul contrôleur et comment faire avec les vues
 
Discussions similaires
Haut