Quero criar um plugin que precise de suas próprias tabelas. Portanto, é uma boa ideia ter geradores de migração e modelos, pois copiá-los manualmente do diretório principal do aplicativo pode levar a erros e é simplesmente pouco conveniente. Então, comecei a criar meus próprios geradores. Comecei pelo gerador de migração:
O gerador de plugins do Rails cria um bin/rails específico do plugin que habilita os geradores de migração e modelo específicos do plugin. Seria bom ter algo assim também. Tentei criar algo semelhante, mas não consegui fazer funcionar, então segui outro caminho e comecei a criar esses geradores “especiais”. Se eu entendesse melhor as diferenças entre a abordagem do Rails e a do Discourse para criar plugins, talvez pudesse seguir essa outra rota, o que poderia economizar tempo. Talvez alguém possa esclarecer isso. Por que os plugins do Discourse e do Rails são coisas diferentes e por que eles não se baseiam um no outro?
Os plugins do Rails são diferentes dos plugins do Discourse por várias razões. Os plugins do Discourse precisam ter uma estrutura de pasta específica; eles podem estender ou substituir o código Ember do núcleo do Discourse, etc. Acredito que a parte do Rails de um plugin do Discourse seria mais próxima de um plugin genérico do Rails, mas não são a mesma coisa.
Além disso, deve-se criar novas tabelas apenas se forem realmente necessárias. O Discourse já possui cerca de 150 tabelas e não é muito comum que sua tarefa não possa ser concluída usando uma ou algumas delas.
Mas, olhando para o futuro, eu pessoalmente gostaria e gostaria de ver isso acontecer. Isso significaria que as pessoas estariam criando plugins enormes e mais emocionantes e se tornando mais criativas com o que pode ser feito com o Discourse.
Eu preciso delas. Até funcionalidades básicas exigem tabelas. Acho realmente irritante que não exista uma maneira clara e documentada de fazer isso. Por exemplo, o plugin de enquetes usa suas próprias tabelas, mas não consigo encontrar o gerador para criá-las. discourse/plugins/poll at main · discourse/discourse · GitHub
Outra vantagem de documentar é que haverá convenções para a criação de namespaces de tabelas e migrações. (Vi algumas soluções realmente complicadas recomendadas aqui nos fóruns sobre como adicionar migrações a um plugin)
Ótimo! Então, qual caminho seguir? Aproximar-se do gerador de plugins do Rails com seu próprio bin/rails na pasta do plugin, ou criar versões próprias para todos os geradores (migrações, modelos, controladores)?
Você precisa ler os tópicos sobre como desenvolver plugins aqui. Para a maioria dos plugins, você pode usar tabelas existentes (como campos personalizados de post). Há momentos em que você precisará de mais tabelas, mas provavelmente será melhor começar com algo menos complexo.
Li o guia para iniciantes sobre plugins e este. Há algo mais? Também examinei o código de alguns plugins. Só sei que preciso de tabelas. E há outros plugins que usam suas próprias tabelas. Por que essa obsessão em não criar novas tabelas? Há um grande custo envolvido na criação de novas tabelas? Especialmente se elas forem nomeadas com o nome do plugin no início, realmente não vejo nenhuma desvantagem.
Estas aqui. Recomendo fortemente que você leia estas com atenção antes de fazer qualquer comentário relacionado ao desenvolvimento. Não é que você nunca precise de tabelas personalizadas, mas estas são essenciais de qualquer forma.
Essa coisa é apenas um armazenamento básico de chave-valor. Não consigo armazenar relações entre tabelas ali. Gosto de SQL. E preciso usá-lo para o plugin que quero criar.
Entendo que esse problema se aplica a pessoas que desejam criar plugins que “pessoas não técnicas” possam instalar e desinstalar. Eu não sou uma dessas pessoas. Portanto, ficaria feliz se pudéssemos voltar ao assunto.
Se a intenção é criar algo que apenas você mesmo vai usar, na minha opinião, provavelmente seria melhor escrever uma extensão de navegador ou um aplicativo de desktop em vez de um plugin. Alguma razão para isso ter de ser um plugin?