Formalisation des routes de contenus

Darks commented

2019-12-22 15:38:20 +01:00

Owner

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.

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.

Darks added the

proposal

label 2019-12-22 15:38:20 +01:00

Lephenixnoir commented

2019-12-22 15:45:21 +01:00

Owner

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}/.

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}/`.

Filoji commented

2019-12-24 16:18:15 +01:00

Collaborator

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 ?

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 ?

Lephenixnoir commented

2019-12-24 16:26:08 +01:00

Owner

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}.

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}`.

Eragon commented

2019-12-24 16:38:21 +01:00

Member

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.

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.

Darks commented

2019-12-25 22:17:49 +01:00

Author

Owner

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…

Pour info, la route `/membre/id/<id>` existe déjà. :wink: Et Lephe a raison, pour le référencement tout mettre à la racine c'est foireux…

Eragon commented

2019-12-28 11:04:32 +01:00

Member

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

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

Filoji commented

2019-12-28 23:42:48 +01:00

Collaborator

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)

Darks commented

2019-12-29 11:34:45 +01:00

Author

Owner

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....

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...`.

Lephenixnoir commented

2020-01-02 07:09:22 +01:00

Owner

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).

Eragon commented

2020-01-03 12:58:10 +01:00

Member

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 ?

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 ?

Lephenixnoir commented

2020-01-03 13:58:23 +01:00

Owner

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

👍 1

Darks commented

2020-07-13 20:39:45 +02:00

Author

Owner

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.

Lephenixnoir commented

2020-07-13 20:44:10 +02:00

Owner

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.)

Lephenixnoir closed this issue

2020-07-13 20:44:19 +02:00

Darks commented

2020-07-16 20:48:40 +02:00

Author

Owner

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")

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")

Darks reopened this issue

2020-07-16 20:48:54 +02:00

Lephenixnoir commented

2020-07-16 21:45:36 +02:00

Owner

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 ?

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 ?

Darks commented

2020-07-16 21:56:05 +02:00

Author

Owner

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 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 ?

Lephenixnoir commented

2020-07-16 22:02:18 +02:00

Owner

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.

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.

Lephenixnoir commented

2020-07-17 00:06:26 +02:00

Owner

Voilà ma version sur dev (17c78204a6).

Voilà ma version sur dev (https://gitea.planet-casio.com/devs/PCv5/commit/17c78204a6421957ead668d9a1c6e9fc8cf2ef00).

Darks closed this issue

2020-07-17 00:27:58 +02:00

Formalisation des routes de contenus #43

Routes de contenus principaux

Routes pour l'édition des commentaires