RailsプラグインとDiscourseプラグインの違いは何ですか?

独自のテーブルを必要とするプラグインを作成したいと考えています。そのため、マイグレーションとモデルのジェネレータを備えていることは非常に有益です。メインのアプリディレクトリから手動でコピーするとエラーが発生しやすく、また便利ではありません。そこで、独自のジェネレータを作成し始めました。まずはマイグレーションのジェネレータから始めました:

次にモデルやコントローラーについても同様のアプローチを続けることもできました。しかし、その後 Getting Started with Engines — Ruby on Rails Guides を読み始め、これらすべてが作業の重複ではないかと感じるようになりました。なぜ Discourse のプラグインジェネレータ は Rails のプラグインジェネレータと大きく異なるのでしょうか?

Rails のプラグインジェネレータは、プラグイン固有の bin/rails を作成し、それによってプラグイン固有のマイグレーションやモデルのジェネレータを利用可能にします。同様の仕組みがあると嬉しいのですが、私も試みましたが動作させることができませんでした。そのため、別の方法として、これらの特別なジェネレータ(いわゆる「特別雪の結晶」のようなもの)を直接作成する道を選びました。Rails と Discourse のプラグイン作成方法の違いをより理解できていれば、時間を節約できるかもしれない別のアプローチを選べたかもしれません。どなたかこの点について詳しく説明していただけませんか?なぜ Discourse と Rails のプラグインは異なるものとして扱われ、互いに構築されていないのでしょうか?

「いいね!」 3

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.

「いいね!」 1

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) ?

「いいね!」 1

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.

「いいね!」 3

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.

「いいね!」 1

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.

「いいね!」 1

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?

「いいね!」 1

Here’s an interesting related discussion:

「いいね!」 5

このトピックは2日後に自動的に閉じられました。返信はもう受け付けられません。