Quiero crear un plugin que necesite sus propias tablas. Por lo tanto, es una buena idea tener generadores de migraciones y modelos, ya que copiarlos manualmente desde el directorio principal de la aplicación puede provocar errores y resulta poco práctico. Así que empecé a crear mis propios generadores. Empecé con el generador de migraciones:
Ahora podría continuar y hacer lo mismo para modelos y controladores. Sin embargo, ahora he comenzado a leer esto Getting Started with Engines — Ruby on Rails Guides y parece que todo esto podría ser una duplicación de esfuerzos. ¿Por qué el generador de plugins de Discourse se desvía tanto del generador de plugins de Rails?
El generador de plugins de Rails crea un bin/rails específico del plugin que habilita los generadores de migraciones y modelos específicos del plugin. Sería agradable tener algo similar. Intenté crear algo así, pero no logré que funcionara, así que tomé el otro camino y simplemente empecé a crear estos generadores especiales. Si hubiera entendido mejor las diferencias entre la forma de Rails y la de Discourse de crear plugins, podría haber seguido esa otra ruta, lo cual podría ahorrar tiempo. Quizás alguien pueda ampliar sobre esto. ¿Por qué los plugins de Discourse y Rails son algo diferente y por qué no se basan mutuamente?
Los plugins de Rails son diferentes de los plugins de Discourse por muchas razones. Los plugins de Discourse deben tener una estructura de carpetas específica; pueden extender o sobrescribir el código Ember del núcleo de Discourse, entre otras cosas. Creo que la parte de Rails de un plugin de Discourse se asemejaría más a un plugin genérico de Rails, pero no son lo mismo.
Además, solo se deben crear nuevas tablas si son realmente necesarias. Discourse ya tiene alrededor de 150 tablas y no es muy común que tu trabajo no pueda completarse utilizando una o un par de ellas.
Sin embargo, mirando hacia el futuro, personalmente me gustaría y desearía ver que eso suceda. Significaría que las personas están creando plugins enormes y más emocionantes, y que están siendo más creativas con lo que se puede lograr con Discourse.
Las necesito. Incluso la funcionalidad básica requiere tablas. Creo que es realmente molesto que no haya una manera clara y documentada de hacer esto. Por ejemplo, el plugin de encuestas usa sus propias tablas, pero no puedo encontrar el generador para crearlas. discourse/plugins/poll at main · discourse/discourse · GitHub
Otra ventaja de documentarlo es que se establecerán convenciones sobre el espacio de nombres de tablas y migraciones. (He visto algunas soluciones bastante truculentas recomendadas aquí en los foros sobre cómo agregar migraciones a un plugin)
¡Genial! Entonces, ¿qué camino tomar? ¿Acercarse más al generador de plugins de Rails con su propio bin/rails en la carpeta del plugin, o crear versiones propias para todos los generadores (migraciones, modelos, controladores)?
Necesitas leer los temas de cómo desarrollar plugins aquí. Para la mayoría de los plugins, puedes usar tablas existentes (como los campos personalizados de publicaciones). Hay momentos en los que necesitas más tablas, pero probablemente te convenga comenzar con algo menos complejo.
He leído la guía para principiantes sobre plugins y esta. ¿Hay algo más? También he revisado el código de algunos plugins. Solo sé que necesito tablas. Además, hay otros plugins que utilizan sus propias tablas. ¿Por qué existe esta obsesión de no crear nuevas tablas? ¿Implica un gran costo crear tablas nuevas? Especialmente si están namespace con el nombre del plugin al principio, realmente no veo el inconveniente.
Estos son. Los recomiendo encarecidamente para que los pruebes antes de hacer cualquier comentario relacionado con el desarrollo. No quiero decir que nunca necesites tablas personalizadas, pero de todos modos estos son imprescindibles.
Esto es simplemente un almacén básico de pares clave-valor. No puedo almacenar relaciones entre tablas allí. Me gusta SQL y necesito usarlo para el complemento que quiero crear.
Entiendo que este problema afecta a quienes desean crear complementos que puedan ser instalados y desinstalados por “personas no técnicas”. Yo no soy una de esas personas. Por lo tanto, agradecería que pudiéramos volver al tema.
Si el objetivo es crear algo que solo tú mismo usarás, en mi opinión, probablemente sería mejor desarrollar una extensión del navegador o una aplicación de escritorio en lugar de un complemento. ¿Hay alguna razón por la que esto deba ser un complemento?