#43 Formalisation des routes de contenus

Aberto
aberto por Darks 6 meses atrás · 11 comentários

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 adicionou a etiqueta
proposal
6 meses atrás
Lephenixnoir comentou 6 meses atrás
Proprietário

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

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 comentou 6 meses atrás
Proprietário

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 comentou 6 meses atrás
Colaborador

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 comentou 6 meses atrás
Proprietário

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…

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 comentou 6 meses atrás
Colaborador

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

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)

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 comentou 6 meses atrás
Proprietário

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/longuewww.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 comentou 6 meses atrás
Proprietário

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

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 comentou 6 meses atrás
Colaborador

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 comentou 6 meses atrás
Proprietário

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

Idée générale : on fait comme Mumble en réutilisant un client existant libre en Javascript.
Acesse para participar desta conversação.
Sem marco
Sem responsável
4 participante(s)
Data limite

Data limite não informada.

Dependências

Esta issue atualmente não tem dependências.

Carregando…
Cancelar
Salvar
Ainda não há conteúdo.