問題タブ [mediator]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
node.js - MongoDB (および mongoose) を使用して NODEJS プログラムで永続化するために Facade+Mediator を実装するのに助けが必要です
私は NodeJS と MongoDB を使って遊んでいます。本当に大きなアプリケーションになりそうなものを作りたいです。そのため、アプリケーションをできる限り切り離して設計するようにしています。
ビジネスロジックがデータの保存方法を認識しないようにするために、永続化レイヤーを抽象化すると便利だと思います(将来、RDBMS用にMongoDBを切り替える必要があるかどうかはわかりません)。それを知って、データストレージに必要な操作を備えた FACADE を作成し、メディエーターのパトロンを使用して FACADE 操作をサブスクライブし、それらを実装することを考えました。このメディエーターは、イベント リスナーを使用してファサードに接続し、ファサードはイベント エミッターを使用します。次に、メディエーターにサブスクライブするモデルにはすべてのマングース スキーマが含まれ、すべてのデータベース/永続性の問題を担当します。(それは意味がありますか?)
私は、マングースがデータモデルに非常にタイトであることを知っています. すなわち。Player プロトタイプではなく、PlayerSchema と PlayerModel があると予想されます。そう:
- マングースのデータ モデルを使用する必要がありますか? (これを行う際に制限/問題はありますか?-DBを切り替えるとそれらを書き直す必要があることに加えて-)
- マングースのデータ モデルをビジネス ロジックのプロトタイプに (この FACADE コンポーネントによって) 変換する必要がありますか? MongoDB データにアクセスするために別の ORM を試す必要がありますか?
私はJavaScript、Node、およびこれらすべてのテクノロジーに非常に慣れていないため、これらの抽象化を本当に行いたいと考えています(したがって、各部分を分離してテストし、より良い解決策がある場合はレイヤーを切り替えられるようにしたいと考えています)。
どんなアドバイスでも大歓迎です!
javascript - RequireJSをはじめ、モジュール間の通信
私は ActionScript 3 開発者で、大規模な JavaScript アプリを作成する最初の方法を作成したばかりです。したがって、私はモジュールを理解し、AMD が使用するのに適したパターンであることを理解しています。RequireJS について読んで実装しました。しかし、私がまだ理解していないのは、クロスモジュール通信を実現する方法です。なんらかのメディエーターが必要であることは理解しています...記事や投稿を読んでも、簡単に実装する方法がわかりませんでした。これが私のコードです。
main.js
Player.js
AssetsManager.js
「ダミー用」のヘルプをいただければ幸いです:)ありがとうございます。
php - mediator.js 実装時の名前空間の問題
組織の登録メンバーが使用する外部アップロードのコンテンツに基づいて、一連の ajax フォームと単純な js hide/show div を処理する Web ページ (php) があります。より保守しやすく拡張可能なサイトを構築するために、私はアーキテクチャ パターンを使用して無限の jQuery 連鎖を防ぐことを検討してきました。つまり、メディエーター パターンです。
Jack Lawson のMediator.jsを使用した人はいますか? 基本的に、メディエーターにサブスクライブして、同じチャネルで何かが発行されたときに実行される関数を使用して「チャネル」(名前空間) をリッスンできます (必要に応じて、応答する前に述語の true/false 関数をチェックすることもできます)。
目標: mediator.js API には大きな可能性があり、有効な xhtml ドキュメントを実装して名前空間を正しく使用する必要があるようです。メディエーター パターンを実装することは、javascript コードを分離し、将来的に複雑な Web アプリをより保守しやすく拡張しやすくするための優れた方法のように思えます。
フラストレーション: 名前空間と mediator.js API によって実装されるメディエーター パターンの両方を理解していると思います。特定の「チャネル」(名前空間) でメディエーターを介して DOM 属性イベントを正常に発行し、それらのチャネルにサブスクライブしてそれらに反応することができました。対応が必要かどうかを確認します。しかし、新しい名前空間が原因で、CSS が要素を認識できなくなりました。
次のような名前空間を作成しました。
そして、それらを次のような html 要素に適用します。
それに応じてcssファイルを変更しました:
それでも、ページの css フォーマットは壊れています。
レンダリングされたページの doctype 部分は次のようになります。
これが必須ではないかどうかは完全にはわかりませんが、追加しようとしました:
次の XML 解析エラーが発生します。
XML 解析エラー: 整形式ではありません
これは、この名前空間定義の等号をxmlns:active='http://www.xxx.com/tracks/active'
問題として指摘していますが、私が読んだすべてのドキュメントは、これが正しい構文であることを示しています。
質問:
- 上記の名前空間を実装した後、CSS が壊れるのはなぜですか?
- ヘッダーに を追加する
<? header('Content-Type: application/xhtml+xml'); ?>
と、前述の解析エラーが発生するのはなぜですか?
助けてくれてありがとう。
javascript - メディエーター pub/sub パターンを使用する場合のバックボーン アプリのルーティング
クリーンなコードベースを維持するために、モジュール間でメッセージを送信するためにhttps://github.com/addyosmani/backbone-aura/のモジュラーおよびファサード/メディエーター pub/sub パターンを組み合わせたバックボーンでアプリケーションを構築しています。
aura のRouter
アプリの例全体を調べてみると、モジュール自体の一部であるルーターの理想的な使用法を説明している readme ファイルしか見つかりませんでした。ウィジェットをレンダリングするために必要なテンプレート。」
set-route
そこで、メッセージを受け取ってルートを設定するルーターモジュールや、メッセージをリッスンするモジュールなど、スケーラブルなルーティングシステム (モジュールが独自のサブルートを指定できるというスケーラブルな意味) を実装するためのソリューションをいくつか試しましたroute
。モジュールごとにサブルーターも使用しました。この問題は、最初のページの読み込み時に、メッセージングの「非同期」の性質のために、グローバル ルーターが URL を解析するまでにルートとそのコールバックが定義されていない可能性があるようです。ルーター モジュールを起動する前に、すべてのメッセージをキューに入れる必要があると想像できます。
何かきれいなものを実装したいのですが、それは理にかなっています。また、最初にすべてのウィジェットのすべてのルートを解析し、次にルーターをインスタンス化する可能性も考えていました。これにより、ルーター モジュールが特殊なケースになるため、モジュールの一部であってはなりません。
Router はメッセージを使用するモジュールである必要がありますか、それとも拡張機能である必要がありますか、またはモジュールがアクセスできるグローバルなアーキテクチャの高次の部分である必要がありますか?
私はこれが負荷の高い質問であることを知っています。事前に助けてくれてありがとう!
javascript - モデルから Backbone Mediator を使用してイベントを発行する
バックボーン モデルからイベントを公開するのは良い習慣/パターンですか?
mvvm - IoC コンテナは Messenger/Mediator クラスを使用できますか?
私は IoC を初めて使用します。ベスト プラクティスにより、コンテナーでメディエーター クラス (MVVM Lite の Messenger など) を使用できるかどうか疑問に思っています。コンテナはメッセージを登録して送信できますか?
どうもありがとうございました!
javascript - バックボーン+RequireJS+メディエーターパターンにより、ビューロジックが短絡し、無限ループが発生しました
私は現在、Backbone.Mediatorを使用して、Backbone+RequireJSプロジェクトでMediatorPatternの利点を活用しています。しかし、それが「設計による」ものなのか、それともMediator Patternの標準的な動作ではなく、プラグインのバグなのかわからない、Patternの特殊な動作に遭遇しました。
不自然な例として:
AMDモジュール1
AMDモジュール2
AMDモジュール3
私はそれがこのように機能すると思いました:
ただし、真実は、チャネル'list:switch'をサブスクライブするView2SiblingDiv
の別のインスタンスであり、作成直後は、チャネル'list:switch'で発生しているイベント信号によってもトリガーされます(これは、後でのみ停止します)。の実行)。SiblingDiv
**View2**.shrinkAndMore();
したがって、実際のコードフローは次のようになります。
無限ループ...おっと!
コードにいくつかの変更を加えることで、自分のやり方で物事を機能させることができました。
AMDモジュール2改造
AMDモジュール3改造
しかし、無限のループ動作(イベント信号のブロードキャスト中に作成された新しいオブジェクトもその信号によってトリガーされる)がメディエーターパターンの方法論で「標準」と見なされるかどうかを理解することに非常に興味がありますか?それとも、これはすべてプラグイン部分の単なるバグですか?