Gracias, @tshenry. No estoy seguro de por qué el código del propietario del grupo no funcionó para mí; probablemente tenga que ver con cómo configuré el plugin.
He descubierto que el enfoque AJAX funciona como un método “MVP”. Por cierto, creo que puedes hacer una llamada a la API a [forum-url]/groups.json para obtener todos los grupos del sitio y luego iterar sobre ellos, por lo que no es necesario hacer múltiples llamadas.
Esperaba preguntar:
–Para el enfoque de API AJAX/JSON, ¿sabes cómo hacer que una función solo se ejecute cuando un usuario va a una página específica? Ahora mismo, si pongo el código AJAX en la sección </head> de mi panel de personalización, puedo hacerlo funcionar, pero se ejecuta cada vez que se carga el sitio (cuando solo quiero que se ejecute cuando se carga la página de índice de grupos).
–En mi caso, estoy usando AJAX ahora mismo especialmente porque no solo necesito mostrar a los propietarios de los grupos, sino también algunas otras características nuevas de un grupo que estoy agregando. Serían como campos personalizados del grupo que estoy intentando recuperar y mostrar. Ahora mismo, la versión “MVP” (mientras aún estoy aprendiendo cómo funciona la base de código de Discourse) es guardarlos en una base de datos separada no relacionada con Discourse que consulto y agrego a la página de índice de grupos.
Obviamente, la solución más limpia sería agregar las características personalizadas a los grupos en la base de datos de Discourse y recuperarlas. Solo estoy tratando de evaluar el tipo de operación que se requeriría aquí. ¿Eso requeriría rehacer una serie de archivos de Discourse (controladores, modelos, plantillas)?
No existe un concepto integrado de campo personalizado para grupos como sí lo hay para campos personalizados de usuario. Creo que necesitarías crear un plugin que agregue todos los componentes necesarios para que funcione.
Tienes razón. Se me olvidaba: eso es algo que también almaceno en una base de datos separada a la que llamo mediante AJAX (y algo de magia adicional) en este momento.
Gran idea: veo lo que hiciste con if ((url == "/") || (url == "/latest") ) en ese repositorio. Puedo hacer algo similar.
Sí, he revisado esa guía, así como las otras que he podido encontrar. Es una excelente guía, pero he encontrado que la transición desde esa guía (y otras en meta) hacia la implementación de este tipo de personalización es complicada. Estas personalizaciones requieren, hasta donde puedo ver, comprender realmente cómo encajan las plantillas, los controladores y los modelos en la base de código de Discourse.
Digresión
Ember puede ser un gran sistema para construir aplicaciones de alto rendimiento, pero encuentro difícil desentrañar cómo se relacionan los diferentes archivos. Por ejemplo, encontrar la plantilla correcta en una vista en el repositorio de GitHub no te dice mucho sobre qué otras plantillas enlaza esa, y mucho menos sobre qué controladores y otros modelos pueden ser relevantes. Es posible, pero avanza lentamente, y realmente necesitas entender esas relaciones para realizar estas personalizaciones.
En Angular, como método alternativo, las piezas de los componentes de vista normalmente se agrupan junto con un archivo HTML, TypeScript y CSS, y luego otros archivos relevantes están claramente marcados en estos archivos (de modo que los servicios en uso se identifican en el archivo TypeScript y otros componentes que se insertan están claramente señalados en el archivo HTML). Por lo que puedo ver, esa no es la forma en que funciona la estructura de Ember en Discourse (no para criticar esa estructura: es una aplicación muy estable y de alto rendimiento; simplemente requiere acostumbrarse).
Por eso estoy usando cosas como AJAX para lograr el mismo resultado mientras continúo tratando de entender cómo encajan las piezas de Discourse.