[Suggestion] url rewriting

[Neurozone]

Réécrire : http://domaine/index.php?action=selectedFeed&feed=91#73988

En

http://domaine/leed/Korben/73988

Qu'en pensez-vous ?

[Sbgodin]

Il faudrait que

http://domaine/leed/Sbgodin/73988

soit converti en

http://domaine/leed/index.php?action=selectedFeed&feedName=Sbgodin.

Donc, il sera nécessaire de générer à l'ajout du flux le feedName avec le risque d'encodage correspondant. Actuellement, c'est une clé qui est utilisée et qui serait inconnue de la règle de réécriture.

Mais si on renomme le flux, faudra-t-il renommer le feedName ? Faudra-t-il laisser à l'utilisateur fixer le feedName ? À ce tarif-là, il faudrait d'abord ne pas utiliser la clé (91 ici) mais directement le feedName.

Donc, développement en deux temps :

1. Création et gestion du feedName en lieu et place de la clé : attention aux caractères autorisés dans ce feedName.
2. Ajout de la réécriture d'url

À quoi ça pourrait servir d'avoir de telles url ?

[Neurozone]

A avoir de belles url dans l'application ?

Et on pourrait même penser à http://domaine/leed/categorie/feed/id

On aurait une lecture directe de la catégorie et du nom du flux. Après il est vrai que ça ne révolutionne rien, mais on pourrait passer facilement d'un flux à l'autre via l'url.

C'est juste une suggestion :)

[Phyks]

Si URL rewriting il doit y avoir, je suis pour qu'elle soit en option. Enfin, personnellement, je n'aime pas l'URL rewriting, qui masque ce qu'il se passe vraiment, derrière des URLs, et ça demande une configuration particulière du serveur (enfin, activer le mod_rewrite quoi).

Je pense notamment aux scripts comme WebSVN qui font de l'URL rewriting en option, si on le souhaite, mais qui ne le font pas de base. D'ailleurs, @Sbgodin, c'est peut être une piste ? Je ne sais plus comment est-ce qu'ils font en détails, mais il me semble que l'URL rewriting passe par un fichier annexe, wsvn.php, qui est chargé de faire les traductions nécessaires. http://www.websvn.info/

[Neurozone]

Une option pour choisir l'url rewriting, un peu comme dans dotclear me semblerait très satisfaisant

[Sbgodin]

La réécriture d'url peut être prise en charge par un contrôleur, façon MVC. Le fichier php interprète toute l'url et se charge de faire lui-même le trevail. Cela nécessite de développer ce composant et évite de se lier à Apache. Ça c'est pour la partie facultative.

Mais il faut aussi que les liens générés par Leed utilisent aussi la réécriture. Il faudrait donc réécrire tous les composants afin qu'ils génèrent la bonne url...

[phardouin]

Bonjour,

@Sbgodin : «À quoi ça pourrait servir d'avoir de telles url ?»

c'est utile également lors de l'utilisation du plugin social en évitant d'avoir des URL trop longues pour les posts vers Twitter par exemple.

[Sbgodin]

On se place alors dans l'optique d'un Leed dont la consultation est publique, donc ? Mais alors pourquoi ne pas fournir le lien d'origine ?

[tetsumaki]

Je ne vois pas trop l'utilité non plus. Si c'est en option, pourquoi pas, mais je ne l'activerais pas.

[tmos]

À partir du moment où ça peut faire plus «clean» c'est bon à prendre selon moi, et tant que ça reste en option je ne vois pas ce qui pourrait aller à l'encontre de cette idée :)

Il faut bien que ça reste en choix par contre (à l'install ?), car il me semble que tous les serveurs ne sont pas systématiquement capables de faire de l'url rewriting.

[pVesian]

+1, on peut être sous nginx par exemple, le rewriting sera pas pareil

Le 1 mai 2014 18:52, Tom.C. notifications@github.com a écrit :

À partir du moment où ça peut faire plus «clean» c'est bon à prendre selon moi, et tant que ça reste en option je ne vois pas ce qui pourrait aller à l'encontre de cette idée :)

Il faut bien que ça reste en choix par contre (à l'install ?), car il me semble que tous les serveurs ne sont pas systématiquement capables de faire de l'url rewriting.

— Reply to this email directly or view it on GitHubhttps://github.com/ldleman/Leed/issues/369#issuecomment-41929399 .

[Sbgodin]

Faute de développement à venir, je clos.