以下のようなプラグインを作成しようとしています。
composer-fieldsの隣に「検索」という新しいボタンが表示される。
ボタンをクリックすると、検索フォームが表示されるオーバーレイがポップアップ表示される。
検索フォームでユーザーは検索語(例えば都市名)を入力でき、独自の画像検索エンジン(APIキーが必要な私のURLで実行される)でその都市の画像を検索する。
上位5枚の画像が表示される。ユーザーが1枚の画像を選択すると、オーバーレイが消え、画像と検索文字列がコンポーザー内にドラフトとして追加される。ユーザーはその後、投稿の続きを書くことができる。
実際のユースケースはもう少し複雑ですが、大まかにはこのようなことを達成したいと考えています。目標は、検索エンジンに手動で行き、画像をコピーしてドラフトを作成するよりも、ユーザーが画像付きの投稿ドラフトをより便利に作成できるようにすることです。
すでに、composer-fieldをコネクタとして使用して新しいボタンを作成することには成功しています。ボタンはクリックでき、アクションをトリガーします。しかし、ここで行き詰まっています。
質問:
私の作業を楽にしてくれるプラグインはありますか? Pavilion wizard pluginを考えていましたが、APIへの呼び出しは有料版のみで提供されていること、そして現時点ではこのプラグインにお金を費やす価値があるかどうかを判断するには時期尚早であることを知りました。
オーバーレイをアクティブ化するためにターゲットにできる適切なCSSクラス/div IDは何ですか?
バックエンド経由でAPI呼び出しを行う方法を理解するための良い例は何ですか?検索エンジンのAPIキーをクライアントに渡したくないので、バックエンド経由で行う必要があります。
プラグインAPIが実際には何であるか、そしてそれが必要かどうかはわかりません。(ドキュメントがあちこちに散らばっていて少し苦労しています。)
その他のヒントやアドバイスも歓迎します。
その間、いくつか有益なリソースを見つけました。これらを「プラグインの書き方」チュートリアルで、より目立つように配置できればと思います。初心者には、それらの存在さえ明らかではありません。
Discourse自身のAPI(プラグイン作成には役立ちませんが、初心者には関連性があります):https://docs.discourse.org/
クライアントプラグインAPI(プラグインのバックエンド作成には役立ちませんが、フロントエンドにとっては間違いなく作業が容易になります):
A versioned API for client side plugins
discourse/app/assets/javascripts/discourse/app/lib/plugin-api.gjs at main · discourse/discourse · GitHub
バックエンドプラグインAPIは基本的にRailsまたはRubyであると理解しましたが、フロントエンドとバックエンドがどのように相互作用するのか、またはバックエンドの最初の「フック」がどこにあるのかは明確ではありません。もちろん、配置するplugin.rbはありますが、このファイルへのエントリポイントに関するドキュメントがあるかどうか疑問に思っています。Ruby on Railsプログラマーにとっては明白かもしれませんが、私はそうではないので、これは急な学習曲線です。
renato
(Renato Atilio)
2025 年 3 月 12 日午後 6:24
3
fabkosta:
(APIキーを必要とする独自のURLで実行中)
バックエンドの変更は必要ないようです。説明されている動作は、当社の「ハイパーリンクの挿入」モーダル の動作と非常によく似ています。トピックを検索し、リンクとして追加するトピックを選択すると、確認時にコンポーザーにリンクが追加されます。
プラグインのアウトレット またはapi.onToolbarCreate をイニシャライザに追加してツールバーに追加し、「ハイパーリンクの挿入」モーダル と同様の方法でモーダルを開くことができます。ツールバーアクションからのtoolbarEvent オブジェクト を活用してコンポーザーにaddText を追加できます(アウトレットが必要な場合は、appEvents トリガー を介してコンポーザーと対話することもできます)。
ありがとうございます。大変参考になります。モーダルはまさに私が探していたものです。ユーザーのフローを中断させ、ユーザーがモーダルを完了したときにのみ、元の状態に戻ります。ハイパーリンク挿入モーダルがどのように機能するか見てみます。
質問: DModal、DButton、その他のDiscourse固有のオブジェクトのドキュメントはどこで見つけられますか?
こちらです:
Discourse 3.1.0.beta6 には、まったく新しい <DModal> コンポーネントベースの API が同梱されています。DModal は UI キット の一部であり、discourse/ui-kit/d-modal からインポートされます。
これは従来のコントローラーベースの API を置き換えます。従来の API は現在非推奨です。旧 API を使用して既存のモーダルがある場合は、こちら のマイグレーションガイドをご覧ください。
モーダルのレンダリング
モーダルは、handlebars テンプレートに <DModal> コンポーネントを含めることでレンダリングされます。適切なテンプレートを持っていない場合は、Using Plugin Outlet Connectors from a Theme or Plugin を確認してください。
シンプルなモーダルは次のようになります:
<DButton
@translatedLabel="Show Modal"
@action={{fn (mut this.modal…
こちらも注目に値します:
Basic Usage
FormKit exposes a single component as its public API: <Form />. All other elements are yielded as contextual components, modifiers, or plain data.
Every form is composed of one or multiple fields, representing the value, validation, and metadata of a control. Each field encapsulates a control, which is the form element the user interacts with to enter data, such as an input or select. The control type is specified via @type on the field. Other utilities, like submit or alert, are …
例については、Discourse/plugins/theme components を参照してください。
フロントエンドとバックエンドがルーティングによってどのように連携されているかを説明している、こちらも非常に重要な記事です。
Discourse は時間の経過とともに複雑さを増しており、バックエンドの Ruby on Rails アプリケーションからフロントエンドの Ember.js アプリケーションまで、データがどのように処理されるのかを理解することは、初心者にとってハードルが高い場合があります。
このチュートリアルでは、Discourse におけるリクエストの全ライフサイクルを示し、独自の URL を持つ新しいページをアプリケーションに構築したい場合に必要な手順を説明します。
まず URL から考える
機能の設計を考える際、私はまずその機能にアクセスするための URL を考えることを好みます。例えば、Discourse の開発中に最後に食べたおやつを表示する管理者向けの機能を構築したいとしましょう。それには /admin/snack という URL が適切です。
この場合:
ブラウザで /admin/snack にアクセスすると、「フルスタック」を使ってスナックが表示されるはずです。つまり、Ember アプリケーションが読み込まれ、スナックを表示するために必要なデータをリクエストします。
…
さらにパズルピースです。
API キーは、/admin/api/keys で安全に保存できます。
ついに、プラグインの作成方法に関する素晴らしいチュートリアルを見つけました。