我想创建一个需要自有数据表的插件。因此，拥有迁移（migration）和模型（model）生成器是个好主意，因为手动从主应用目录复制它们不仅容易出错，而且非常不便。所以我开始开发自己的生成器。我先从迁移生成器入手：
接下来我可以为模型和控制器做同样的事情。但现在我开始阅读 https://guides.rubyonrails.org/engines.html，这让我觉得所有这些工作可能是在重复劳动。为什么 Discourse 插件生成器 与 Rails 插件生成器如此不同？
Rails 插件生成器会创建一个专用于该插件的 bin/rails 文件，从而启用该插件特有的迁移和模型生成器。如果能拥有类似的功能就好了。我也尝试过实现类似的东西，但无法使其正常工作，因此我另辟蹊径，直接开始创建这些特殊的生成器。如果我能更清楚地理解 Rails 插件与 Discourse 插件在实现方式上的差异，或许就能选择另一条路径，从而节省时间。也许有人能对此进行补充说明。为什么 Discourse 插件和 Rails 插件是不同的概念，它们为何不能相互构建？
Rails plugins are different from Discourse plugins due to many reasons. Discourse plugins need to have a specific folder structure, they can extend/override the ember code of the core discourse etc. I think the rails side of a discourse plugin would be closer to a generic rails plugin but they aren’t the same things.
Moreover, one should only create new tables if they’re really needed. Discourse already has ~150 tables and its not too often that your job isn’t done using one or a couple of them.
But, moving forward, I personally would wish and like to see that happen. It would mean people are building huge and more exciting plugins and getting more creative with what could be done with Discourse.
I need them. Even basic functionality needs tables. I think its really annoying that there is no clear documented way on how to do this. For example the poll plugin uses its own tables, but I cant find the generator for how to make them. discourse/plugins/poll at main · discourse/discourse · GitHub
Another benefit from documenting is that there will be conventions on table/migration namespacing. (I saw some really hacky solutions recommended here in the forums on how to add migrations to a plugin)
Nice! So which way to go? moving closer to the rails plugin generator with own bin/rails in the plugin folder, or own versions for all the generators (migrations/models/controllers) ?
You need to read the plugin development howto topics here. For most plugins you can use existing tables (like post custom field). There are times that you need more tables, but you’d probably do well to start with something less difficult to start.
I read the beginners plugin guide and this . Is there something else? I also looked at the code of some plugins. I just know that I need tables. And there are other plugins as well that use their own tables. Why is there this obsession with not creating new tables? Is there a big cost involved with creating new tables? Especially if they are namespaced with the plugin name at the beginning I really dont see the downside.
https://meta.discourse.org/t/creating-routes-in-discourse-and-showing-data/48827/19?u=fzngagan
These ones here. I highly recommend these ones hands on before making any comment about anything related to dev. Not to say you might not need custom tables ever but these are must anyway.
this thing is just a basic key value store. I cant store relations between tables there. I like SQL. And I need to use it for the plugin I want to create.
I can understand this problem applies to people that want to create plugins that “non technical people” can install and uninstall. I am not one of those people. So I would be glad if we could go back to the topic.
If the intent is to create something only you yourself will be using, IMHO it would likely be better to write a browser extension or a desktop app instead of a plugin. Any reason this must be a plugin?
Here’s an interesting related discussion:
此主题在 2 天后自动关闭。不再允许回复。