独自のテーブルを必要とするプラグインを作成したいと考えています。そのため、マイグレーションとモデルのジェネレータを備えていることは非常に有益です。メインのアプリディレクトリから手動でコピーするとエラーが発生しやすく、また便利ではありません。そこで、独自のジェネレータを作成し始めました。まずはマイグレーションのジェネレータから始めました：
committed 02:33AM - 19 Aug 19 UTC
the post_migration generator was used as an inspiration.
次にモデルやコントローラーについても同様のアプローチを続けることもできました。しかし、その後 Getting Started with Engines — Ruby on Rails Guides を読み始め、これらすべてが作業の重複ではないかと感じるようになりました。なぜ Discourse のプラグインジェネレータ は Rails のプラグインジェネレータと大きく異なるのでしょうか？
Rails のプラグインジェネレータは、プラグイン固有の bin/rails を作成し、それによってプラグイン固有のマイグレーションやモデルのジェネレータを利用可能にします。同様の仕組みがあると嬉しいのですが、私も試みましたが動作させることができませんでした。そのため、別の方法として、これらの特別なジェネレータ（いわゆる「特別雪の結晶」のようなもの）を直接作成する道を選びました。Rails と Discourse のプラグイン作成方法の違いをより理解できていれば、時間を節約できるかもしれない別のアプローチを選べたかもしれません。どなたかこの点について詳しく説明していただけませんか？なぜ Discourse と Rails のプラグインは異なるものとして扱われ、互いに構築されていないのでしょうか？
fzngagan
2019 年 8 月 29 日午後 12:20
2
Rails プラグインは、多くの理由により Discourse プラグインとは異なります。Discourse プラグインは特定のフォルダ構造を持つ必要があり、コアの Discourse の Ember コードを拡張またはオーバーライドすることができます。Discourse プラグインの Rails 側は一般的な Rails プラグインに近いと考えられますが、両者は同じものではありません。
さらに、本当に必要な場合のみ新しいテーブルを作成すべきです。Discourse にはすでに約 150 のテーブルがあり、1 つまたは数つのテーブルを使用すれば、ほとんどの作業は完了することがほとんどありません。
しかし、今後については、個人的にはそのような動きが生まれることを望み、歓迎します。それは、人々がより大きく、よりエキサイティングなプラグインを構築し、Discourse で何ができるかについてより創造的になることを意味します。
私はそれらを必要としています。基本的な機能であってもテーブルが必要です。これを行う明確なドキュメントがないことが本当に面倒だと感じています。例えば、poll プラグインは独自のテーブルを使用していますが、それらを作成するためのジェネレーターが見つかりません。discourse/plugins/poll at main · discourse/discourse · GitHub
素晴らしい！では、どちらの方向に進むべきでしょうか？プラグインフォルダ内に独自の bin/rails を持つ Rails プラグインジェネレーターに近づけるのか、それともすべてのジェネレーター（マイグレーション、モデル、コントローラー）の独自バージョンを作成するのか？
pfaffman
2019 年 8 月 29 日午後 12:39
4
プラグイン開発のハウツートピックをこちらでお読みください。ほとんどのプラグインでは、既存のテーブル（投稿のカスタムフィールドなど）を使用できます。より多くのテーブルが必要な場合もありますが、まずは難易度の低いものから始めるのが良いでしょう。
初心者向けのプラグインガイドとこちら を読みました。他に何かありますか？また、いくつかのプラグインのコードも確認しました。テーブルが必要であることだけわかっています。そして、独自のテーブルを使用する他のプラグインもあります。なぜ新しいテーブルを作成することにこれほど執着するのでしょうか？新しいテーブルを作成することには大きなコストがかかるのでしょうか？特に、プラグイン名を先頭に付けて名前空間化されている場合、デメリットは本当に見当たりません。
fzngagan
2019 年 8 月 29 日午後 1:04
6
https://meta.discourse.org/t/creating-routes-in-discourse-and-showing-data/48827/19?u=fzngagan
I’ve only just started but here’s my ‘starter for 10’ to get you going:
Read:
these
this
Try and read the code on the simplest, but popular plugins and see if you can understand what they are doing (this is not always easy, especially with the complexity of dealing with multiple files and the sometimes brutal functional brevity of javasctipt, but persevere)
You need to learn:
Lots of Javascript (look no further than @mpj ’s Fun Fun Function excellent & fun (!) videos (thanks man!))
Lots of …
これらをご覧ください。開発に関するコメントをする前に、これらをぜひ実際に試すことを強くお勧めします。カスタムテーブルが決して必要ないわけではないかもしれませんが、いずれにせよこれらは必須です。
# frozen_string_literal: true
# API to wrap up plugin store rows
class PluginStore
attr_reader :plugin_name
def initialize(plugin_name)
@plugin_name = plugin_name
end
def get(key)
self.class.get(plugin_name, key)
end
def get_all(keys)
self.class.get_all(plugin_name, keys)
end
def set(key, value)
self.class.set(plugin_name, key, value)
show original
この仕組みは単なる基本的なキーバリューストアです。テーブル間の関係をそこに格納することはできません。私は SQL が好きです。また、私が作成したいプラグインではそれを使用する必要があります。
Note that if you are developing a plugin, discourse provides a PluginStore to help you avoid migrations, since undoing then when the plugin gets uinstalled is a open problem.
この問題は、「非技術的な人々」がインストールおよびアンインストールできるプラグインを作成したい人々に当てはまることは理解できます。私はそのような人々ではありません。したがって、話題を元に戻していただければ幸いです。
もし、自分自身だけが使用するものを作成する意図であれば、IMHO、プラグインとするよりもブラウザ拡張機能やデスクトップアプリとして作成する方がおそらく良いでしょう。なぜこれが必ずしもプラグインでなければならないのでしょうか？