Merci, @tshenry. Je ne sais pas pourquoi le code du propriétaire du groupe ne fonctionnait pas pour moi—c’est probablement lié à la façon dont j’ai configuré le plugin.
J’ai constaté que l’approche AJAX fonctionne comme une méthode « MVP ». Au fait, je pense que vous pouvez faire un appel API vers [forum-url]/groups.json pour récupérer tous les groupes du site, puis parcourir les résultats depuis là, ce qui évite de devoir faire plusieurs appels.
J’espérais vous demander :
–Pour l’approche AJAX/JSON API, savez-vous comment faire en sorte qu’une fonction ne s’exécute que lorsqu’un utilisateur accède à une page spécifique ? Pour l’instant, si je place le code AJAX dans la section de mon tableau de bord personnalisé, cela fonctionne, mais il s’exécute à chaque chargement du site (alors que je ne veux qu’il s’exécute que lorsque la page d’index des groupes est chargée).
–Dans mon cas, j’utilise actuellement AJAX surtout parce que je dois non seulement afficher les propriétaires de groupes, mais aussi quelques autres nouvelles caractéristiques des groupes que j’ajoute. Il s’agirait de champs personnalisés du groupe que j’essaie de récupérer et d’afficher. Pour l’instant, la version « MVP » (tandis que j’apprends encore comment fonctionne la base de code de Discourse) consiste à les enregistrer dans une base de données externe à Discourse, que je consulte et dont j’extrais les données pour les ajouter à la page d’index des groupes.
Évidemment, la solution la plus propre consisterait à ajouter les caractéristiques personnalisées aux groupes dans la base de données de Discourse et à les récupérer. J’essaie simplement d’évaluer le type d’opération que cela impliquerait. Cela nécessiterait-il de modifier un grand nombre de fichiers de Discourse (contrôleurs, modèles, modèles de vue) ?
Il n’existe pas de concept intégré de champ de groupe personnalisé comme c’est le cas pour les champs utilisateurs personnalisés. Je crois que vous devrez créer un plugin qui ajoute tous les éléments nécessaires pour que cela fonctionne.
Vous avez raison. J’avais oublié — c’est quelque chose que je stocke également dans une base de données séparée, que j’appelle actuellement via AJAX (et quelques autres astuces).
Bonne idée — je vois ce que vous avez fait avec if ((url == "/") || (url == "/latest") ) dans ce dépôt. Je peux faire quelque chose de similaire.
Oui — j’ai parcouru ce guide ainsi que les autres que j’ai pu trouver. C’est un excellent guide, mais j’ai constaté que la transition entre ce guide (et d’autres sur Meta) et la mise en œuvre de ce type de personnalisation est délicate. Ces personnalisations nécessitent, autant que je puisse en juger, une bonne compréhension de la manière dont les modèles, les contrôleurs et les modèles s’articulent dans la base de code de Discourse.
Digression
Ember peut être un excellent système pour créer des applications performantes, mais je trouve difficile de démêler comment les différents fichiers sont liés. Par exemple, trouver le bon modèle dans une vue sur le dépôt GitHub ne vous renseigne pas beaucoup sur les autres modèles auxquels celui-ci fait référence, et encore moins sur les contrôleurs et autres modèles pertinents. C’est possible, mais lent, et il faut vraiment comprendre ces relations pour réaliser ces personnalisations.
Dans Angular, en tant que méthode alternative, les éléments des composants de vue sont normalement regroupés avec un fichier HTML, TypeScript et CSS, puis les autres fichiers pertinents sont clairement indiqués dans ces fichiers (ainsi, les services utilisés sont identifiés dans le fichier TypeScript et les autres composants insérés sont clairement marqués dans le fichier HTML). Autant que je sache, ce n’est pas ainsi que fonctionne la structure Ember de Discourse (ceci n’est pas une critique de cette structure — c’est une application très stable et hautement performante — il faut simplement s’y habituer).
D’où mon utilisation de techniques comme AJAX pour obtenir le même résultat pendant que je continue d’essayer de comprendre comment les éléments de Discourse s’assemblent.