En realidad, eso no es un problema trivial. Por un lado, tienes que manejar muchos casos en el frontend. Aún no he manejado todos los casos para este complemento. Como puedes ver, la capacidad de revisión sigue en la lista de tareas pendientes. Luego está el problema de guardar los datos y si es una buena idea usar la tienda de complementos o no. El tema se aborda en este hilo:
También escribí este complemento porque quería averiguar si las tablas reales pueden realmente aportar un gran beneficio. Toda esta lógica de dependencias y la verificación de errores en el backend con un rollback si es solo un “disparo” en seco no serían posibles usando solo la tienda de complementos. Creo que es un compromiso. Para algunos casos de uso, la tienda de complementos es suficiente. Pero creo que para hacer cosas más complejas no hay otra opción que usar tablas “reales”. También quiero escribir una entrada de blog sobre esto después de explorar un poco más el tema. Si lo vemos de manera más abstracta, lo que queremos hacer es esto: queremos usar Discourse para editar datos estructurados de forma colaborativa. En este momento es realmente difícil “simplemente agregar” un campo personalizado a una publicación o tema, pero creo que se puede facilitar. Otra cosa que quiero hacer es eliminar completamente el editor del compositor y usar el tema solo para la entrada de datos. No sé qué saldrá de esto, pero aquí hay algunas ideas:
Quizás estos dos tipos de complementos también se puedan combinar como explico en este problema de GitHub. Así, ingresas datos en temas que no tienen el editor d normal, sino un editor especializado para la entrada de datos, y luego haces referencia a estos datos en temas que aún tienen el editor d. Estos otros temas también podrían tener algunos campos adicionales, como en este complemento de gestión de proyectos.
Toma todo esto con un grano de sal, ya que no he tenido tiempo de probarlo adecuadamente. Haré un resumen sobre esto cuando regrese de mis vacaciones 