Formalisation des routes de contenus #43

Ce ticket a pour but de faire une page de Wiki dédiée, faisant office de référence tant pour la partie technique que les arguments qui nous ont poussé à faire les choix.

On avait eu une discussion là dessus, mais vu qu'on a rien formalisé sur le moment, ben retour au point mort.

Grossièrement, les url relous sont celles avec plusieurs paramètres optionnels, slug, page et mode édition entre autres.

Routes de contenus principaux

J'avais proposé, pour les routes de forum (et similairement celles des programmes, tutoriels, etc.)

{base}/{id} # url raccourcie
{base}/{id}/{slug} # url longue pour le référencement
{base}/{id}/{page} # url raccourcie menant sur une page
{base}/{id}/fin # url raccourcie menant sur la dernière page
{base}/{id}/{page}/{slug} # url longue menant sur une page
{url sus-citée}?editer # url affichant le formulaire de modification
{url sus-citée}?supprimer # url affichant le formulaire de suppression

Routes pour l'édition des commentaires

Pour l'édition des messages, je pensais à une url unique pour tous les contenus (genre /posts/{id}) mais après réflexion je trouve ça foireux. Vaut sûrement mieux faire une fonction unique mais routant plusieurs url.

Exemple {base}/route-pour-editer fonctionne identiquement quelque soit base

Le principal avantage que j'y vois, c'est que les droits restent gérés au niveau de la route : quelqu'un n'ayant pas accès à /forum/admins se prendra une 403 quoi qu'il arrive (puisque c'est le routeur qui lève l'erreur). Il suffit ensuite de ne vérifier que les droits d'édition (être l'auteur ou bénéficier de edit-post).

Par contre je n'ai pas vraiment de proposition qui me convienne à présenter, donc à voir.

Right, donc quelques remarques pour moi.

Je pense que les slugs sont utilisés au mieux quand ils sont optionnels et qu'il n'y a rien après. (C'est le cas ici.)
C'est mieux aussi s'il n'y a pas d'ambiguité, par exemple entre un nombre et un slug.
Pour les pages non référencées, c'est moins important.

Les routes que tu proposes me semblent pas mal. J'avais proposé /{id}-{page}/ pour les numéros de page, de sorte d'éviter les ambiguités. C'est la seule suggestion que je pense importante ici.

Effectivement tu soulèves un point important avec la gestion des permissions. Je vois pas de raison de ne pas séparer. Je n'ai pas de préférence entre ?editer ou /editer ou autre (edit: à part que /editer crée plein d'ambiguités).

ACK pour ce système, avec ou sans ma suggestion /{id}-{page}/.

J'ai eu une idée : Imaginons : j'ai mon ID de profil qui est 31415, l'ID d'un de mes topic qui est 926535 et que j'ai 35 réponses dessus avec 6 pages; Je pourrais donc avoir comme URL :

https://www.planet-casio.com/Fr/p-31415 Pour un profil
https://www.planet-casio.com/Fr/f-926535 Pour un topic/Forum
https://www.planet-casio.com/Fr/f-926535-m-30 Pour la 30ème réponse
https://www.planet-casio.com/Fr/f-926535-p-4 Pour la 4ème page Bonne idée ou pas ?

Le coup d'avoir p-4 ou m-30 rejoint quelque chose que j'ai voulu proposer : compter les topics non en pages mais en numéros de posts pour que chacun puisse changer le nombre de réponses par page.

Du reste, le fait d'avoir une URL unique, /Fr/{id} c'est une mauvaise idée. Ce n'est pas clair pour l'utilisateur, et pas non plus pour le référencement. Il est nécessaire de bien avoir une hiérarchie, du genre /forum/actus/{id}.

Déjà... /Fr/* n'existe plus,
et sinon... j'aime pas ton idée, j'explique : /membre/eragon montre déjà le profil, pourquoi rendre moins lisible l'url ? Ok on peut mettre le support de l'id en plus du pseudo(membre/{id}), mais pas question de changer cet url.
Pour les autres urls proposés, utiliser uniquement l'id n'est pas lisible et séparer les différents séparateurs de l'url avec des -... c'est pas vraiment lisible. Mais en plus utiliser uniquement la première lettre du mot rend l'url impossible à lire.

Pour info, la route /membre/id/<id> existe déjà. 😉

Et Lephe a raison, pour le référencement tout mettre à la racine c'est foireux…

Ah c'est /membre/id/<id> Je croiyais que c'était directement /membre/<id>ou<name>

J'ai eu une autre idée : Garder vos URLs avec arborescence et, en plus, à la manière de bitly, faire des URLs cours qui redirigent vers les "bons" URLs, ainsi, dans la shoutbox par exemple, avoir des URLs beaucoup plus moins imposant (En parlant de la shoutbox, sinon, pour les URLS, faire comme pour les sujets et ne montrer genre que ">>>Lien<<<" avec un hyperlien et personaliser en fonction de paramètres, parce que les liens énormes sont énervant dans la Shout)

Pour ce qui est du forum, on a défini une syntaxe Lightscript : :<content id> affiche un lien propre vers le contenu en question.

Concernant la shout, ben ça dépendra de ton client IRC. De mémoire certains raccourcissent les url automatiquement, par exemple https://www.planet-casio.com/une/url/un/peu/longue → www.planet-casio.com/une/ur....

Soit dit en passant ce petit bout de syntaxe pour les crossrefs et l'une des principales raisons pour avoir Lightscript. Je sais qu'il a été suggéré d'utiliser un Markdown modifié à la main. Si vous voulez faire ça il faudra implémenter cette syntaxe (en plus d'un tas d'autres détails techniques).

En parlant d'IRC, on à prévu de mettre en place un client web sur le site ou alors juste une page qui explique comment configurer un client autre ?
Est-ce qu'on fait comme pour mumble ou alors on donne juste une page statique avec une explication de comment configurer un client irc de base ?

Idée générale : on fait comme Mumble en réutilisant un client existant libre en Javascript.

Bon, histoire de clore le ticket je pense partir sur ma proposition principale. On pourra toujours interdite les topics dont le nom est un nombre décimal. Ça me parait être suffisament peu fréquent pour que ce ne soit pas pénalisant.

Dans ton premier message il n'y a pas d'ambiguité car l'ID est toujours présent, perso ça me va très bien. (Les URLs en français piquent toujours un peu mais c'est partout comme ça donc rien à changer ha ha.)

Je rouvre, parce que c'est pas encore intégré.

Je suis bloqué sur ce point, c'est assez relou je dois vous avouer.

Le problème que je rencontre est que la page est incluse entre l'id du topic et le slug. Ce qui fait que le Converter doit traiter deux objets en même temps. Sauf qu'on veut pouvoir en utiliser qu'un (le topic) ou les deux.

On veut aussi pouvoir réutiliser le Converter sur d'autres contenus, par exemple les programmes.

J'hésite à créer une classe bateau ContentPaginated ou un truc du style, de manière à pouvoir facilement travailler sur l'objet, qu'il y ait une page ou non (pour rappel, la page peut prendre des valeurs dans ℝ+∪"fin")

Dans la mesure où base/{id} est fixée, la suite devrait aller non ? Ton converter accepte tout y compris les slashs. Ensuite s'il y a un slash c'est {page}/{slug} et tu parses. S'il n'y a pas de slash, c'est soit {page} soit {slug} et tu désambigues selon si int() accepte la chose. La valeur de retour est une paire. Ou bien j'ai loupé quelque chose ?

Le problème, c'est pas tant découper l'url, mais de faire un to_url.

Si je fais une route type /forum/<forum:f>/<int:t>/<pageslug:ps>, comment je créé le slug à partir du numéro de page uniquement ?

J'essaie de tordre le problème dans tous les sens, j'arrive pas à poser un truc propre. Si tu as un moment pour le faire, je dis pas non.

La solution à coup de classe intérmédiaire fonctionne, mais c'est lourd et pas efficace du tout (j'ai des conversions dans tous les sens, avec en plus d'appels à la BDD…)

Edit: je suis le seul à me taper des 500 de Gitea quand je commente ?

Le to_url() est appelé quand tu utilises url_for(), auquel cas tu donnes en argument un peu ce que tu veux. Rien ne t'empêche de demander une paire contenant les deux informations (le topic et la page), voire même que le topic, ou le topic et une valeur spéciale pour la fin. C'est toi qui contrôles l'information disponible tant que tu arrives à la fournir au moment du url_for() ^^

Je peux regarder, faut juste que tu confirmes que je peux pousser sur dev sans te gêner.

Voilà ma version sur dev (17c78204a6).