Puis-je utiliser l'API JSON au lieu de créer un plugin ?

Dev
1

Je travaille sur certaines personnalisations (telles que décrites ici et ici) qui semblent nécessiter une bonne maîtrise d’Ember et de Rails, ainsi que de la manière dont le code source sous-jacent de Discourse s’articule.

En conséquence, la progression est lente (je suis plus habitué à Angular et JavaScript, et je découvre Discourse), je cherche donc des moyens de déployer ces personnalisations plus rapidement.

Voici donc ma question : au lieu de créer un plugin qui manipule les modèles de Discourse, pourrais-je obtenir le même résultat final en utilisant l’API JSON ?

Maîtriser l’API semble plus efficace que de maîtriser Ember et le code source de Discourse, et cela pourrait être implémenté avec des langages comme JavaScript pur ou jQuery.

Je pense que la réponse est oui. Comme l’a dit l’équipe, tout ce que fait Discourse peut être réalisé via l’API.

Je suppose que cela peut fonctionner, mais voici la raison de ma question : le cas d’usage habituel de l’API JSON, à mon avis, concerne une application distincte qui souhaite interagir avec l’application Discourse. Dans mon cas, il s’agirait de l’application Discourse appelant sa propre API.

Par exemple, j’avais précédemment demandé comment récupérer et afficher les propriétaires de groupes de chaque groupe sur la page d’index des groupes. Normalement, on créerait un plugin pour cela.

Dans mon cas, je ferais quelque chose comme ceci : dans mon tableau de bord de personnalisation, sous la balise <head> — appeler une fonction AJAX lors du chargement de la page d’index des groupes, qui envoie une requête API pour récupérer les propriétaires de chaque groupe, puis insère ces informations dans chaque liste de groupe.

Est-ce que cela fonctionnerait ? Devrais-je générer une clé API pour cela, étant donné que la requête provient de l’application elle-même ?

2 « J'aime »
2

Le problème, c’est que si vous souhaitez stocker un nouveau type de données, vous avez besoin d’un plugin. Le serveur doit savoir où stocker les données, quel format est acceptable, qui a le droit de voir les données et qui a le droit de les modifier.

Les identités des propriétaires de groupes sont accessibles publiquement, de sorte qu’un composant de thème pourrait les charger et les afficher sur la page d’index des groupes, mais lentement.

Pour les sujets en vedette des catégories, il existe en réalité certains thèmes et plugins qui utilisent des balises pour mettre cela en œuvre. Les avez-vous déjà consultés ?

5 « J'aime »
3

Cool. Je ne chercherais probablement pas à stocker un nouveau type de données. Plutôt, je travaillerais avec des champs personnalisés, en suivant le format préexistant de ces champs.

Je n’avais pas vu auparavant de plugins pour mettre en avant des sujets dans les catégories. L’essentiel pour moi est de donner aux modérateurs des catégories la possibilité de les sélectionner. Je vais jeter un coup d’œil.

Concernant l’utilisation de l’API pour afficher les propriétaires de catégories et d’autres informations que je récupérerais via l’API : il serait logique que ce soit un peu plus lent que le processus de construction normal, mais j’espère que cette méthode ne sera pas trop lente (je pense que cela fonctionnerait sur des sites qui récupèrent normalement des informations via des API pour remplir les données).

1 « J'aime »
4

Vous ne pouvez déclarer de nouveaux champs personnalisés (et les sérialiser) que dans un plugin.

2 « J'aime »