Discussion :

[MastaKillah]

Bonjour,

Développeur passionné mais occasionnel depuis des années, je m'efforce de faire évoluer avec le temps un projet de framework PHP adapté à mes besoins personnels. Evidemment avec les années le projet est devenu plus gros et j'en viens à le repenser en m'inspirant des bonnes pratiques apprises dernièrement, ainsi que des frameworks existants sur le marché.

Et parfois sur certains aspects, je dois faire des choix. Par exemple, j'ai choisi de ne pas utiliser de système évolué de templating pour l'instant, PHP étant à mon goût suffisamment capable de gérer ça tout seul. Ca ne m'empêche pas d'avoir une structure MVC correcte et donc des templates les plus propres possibles.

Concernant le routing, c'est une autre paire de manche. Je m'efforce depuis quelques temps d'essayer de comprendre l'intérêt d'un système de routing tel qu'il est habituellement présenté. Que ça soit dans les tutos ou au sein des frameworks existants, tous les systèmes de routing semblent se baser sur une liste de routes stockée dans un fichier XML ou JSON... Et j'ai vraiment du mal à comprendre l'intérêt de mettre en place une telle fonctionnalité quand je peux organiser mon application selon une arborescence type "/modules/module/action.act.php" et donc laisser reposer ma gestion des routes sur une détection automatique des arguments passés à l'URL. Détection basée sur une convention simple : le premier argument correspond toujours au module, le deuxième à l'action souhaitée. Je trouve que ça suffit pour connaitre le fichier à inclure et la classe à instancier.

J'ai commencé à me dire que cela pouvait aider à gérer des URL type "0000-titre-de-l-article.html". Mais c'est également faisable en base de données, directement dans les tables stockant les ressources ciblées (donc la table "articles" selon l'exemple présent).
Ensuite, j'ai songé qu'en cas de modification du lien, stocker l'ensemble des routes permet de gérer les redirections à appliquer, et donc c'est utile pour le SEO. Mais là encore, c'est gérable en base de données, et avec une requête correctement écrite on n'a pas besoin d'en rajouter une supplémentaire.
J'ai encore cherché... et je ne trouve pas d'avantage flagrant. Je ne comprends pas pourquoi les "bonnes pratiques" veulent que l'on s'impose le parsing d'un fichier XML + un appel à la DB quand on peut se permettre de ne faire que l'appel à la DB.

Si quelqu'un a la réponse, je suis preneur... cela m'évitera peut-être de faire un choix précipité et de revenir sur ma décision dans quelques mois. ^^


tl;dr : A quoi ça sert de stocker les routes dans un fichier XML/JSON plutôt que de reposer sur des conventions et une base de données adaptée ?

[Spartacusply]

organiser mon application selon une arborescence type "/modules/module/action.act.php" et donc laisser reposer ma gestion des routes sur une détection automatique des arguments passés à l'URL

Pour les autres frameworks je sais pas, mais c'est exactement comme cela que fonctionne CakePhP http://book.cakephp.org/2.0/fr/development/routing.html

[MastaKillah]

Merci, en effet Cake fait partie de ceux que je n'ai jamais eu l'occasion de tester.
Mais ça ne répond pas à ma question qui porte bel et bien sur le pourquoi. C'est toujours sympa de trouver un outil déjà existant qui s'approche du fonctionnement souhaité, mais en l'occurrence là ça ne m'explique pas l'intérêt d'utiliser un fichier XML/JSON qui liste toutes les routes. J'ai du mal à concevoir que ce soit totalement remplaçable par ma technique, les avantages et inconvénients doivent forcément être différents mais je pense que certains m'échappent.

[MastaKillah]

Je me permets un petit up, je n'ai toujours pas trouvé la réponse à ma question... Ca serait cool si quelqu'un pouvait m'éclairer, mes recherches ne donnant rien.

[Aurélien LEQUOY]

c'est marrant j'ai la même démarche que toi =)

j'ai crée ce framework : https://github.com/Esysteme/glial

(en gros ça reprend tous les principes que tu as énoncé et d'autres encore.)

Mon routing est a chier pour le moment, mais je travail dessus.

l’intérêt est uniquement pour le SEO, sinon c'est très limité.


Un cas concret qui ne marche pas et qui a besoin d'un routing : si jamais tu veux utilisé une url du type species/class

le problème est que on ne peut pas définir de méthode "class" et donc routing obligé dans ce cas là.



Si tu veux te joindre à moi tu es le bienvenue , en gros tous les composants chargés => 0.6Mo utilisé chargé en 0.02 sec / 0.2sec => base distante

[grunk]

L'intérêt d'un routing stocké dans des fichiers (xml,php,json ...) c'est que c'est très maléable. On est pas obligé de suivre l'habituel /module/action/parametres.
Du coup ça a un vrai intérêt SEO. Ca permet aussi de faire plus ou moins simplement des routes internationalisées (qui change selon la langue choisi).
Et dernier point qui me semble important , ça permet d'abstraire le système de fichiers , ce qui ajoute une couche de sécurité supplémentaire.

L'intérêt d'un fichier c'est que c'est plus rapide qu'un appel à la DB et que généralement on va venir mettre en cache l'objet PHP généré à partir de ce fichier.

Mon framework se base sur le très classique /module/action/parametres avec possibilité de légère modification via des règles qui permettent de matché une url avec certains controller. Je trouve ça pratique et bien plus simple que devoir me farcir des fichier de config à chaque fois que j'écris un controller.

[Tsilefy]

Le fait de stocker les routes dans un fichier php, xml, yaml, json ou dans la base de données importe peu finalement. Rien ne t'empêche par exemple d'utiliser le routing de symfony et de créer tes routes à partir d'une interface d'administration liée à une bdd (et s'il y a des contraintes de rapidité, on peut toujours dumper les routes dans un fichier, voire mettre ce fichier en cache). La question se pose plutôt sur l'utilité d'utiliser une/des classes de routing spécifiques.

Cela permet:
- de ne pas lier les routes non seulement à l'arborescence, mais même à l'application. Que tu passes de symfony à laravel à ton framework maison, tu gardes tes urls, ce qui est appréciable non seulement en termes de SEO et pour tes visiteurs.
- de découpler ton code (l'une des choses les plus importantes en POO), et de ne pas lier la structure de ton application à la structure de tes urls
- de transférer le routage d'Apache (ou nginx) à php. Fare du routage le serveur web (mod_rewrite) n'est plus flexible dès lors qu'on utilise plusieurs modèles de routes obligeant à modifier à chaque fois un htaccess (tu fais une faute de frappe et tout le serveuer est inaccessible, tu ne peux pas stocker les routes en bdd, etc...)
- de garder le contrôle de ton application: les urls autorisés sont en liste blanche, aucune chance qu'un robot en quête de vulnérabilités puisse tomber accidentellement sur une route non prévue.
- de pouvoir déboguer les routes très facilement, puisque tu sais où aller pour trouver la liste de tes routes sans devoir parcourir tes répertoires pour identifier les contrôleurs, voire les méthodes des contrôleurs. Plus de "magie", tout est explicite.

- les routes sont des objets comme les autres, que tu peux ensuite utiliser, afficher et manipuler dans ton application. C'est pratique pour faire un sitemap, ou des statistiques, ou faire des redirections interners, ou afficher des liens, et que sais-je encore...