2

次の状況を処理するために、リアクティブ バナナがどのように設計されたのか疑問に思っています。

中心的なデータ構造があるとしましょう。ユーザーは、データを表示し、ユーザーがデータを変更できるようにするさまざまな種類のウィンドウをいくつでも自由に開いたり閉じたりすることができます。

その性質上、一つの大きなネットワークを作るだけではうまくいかないと思います。これは、各ウィンドウにネットワークがあり、何らかの形で接続されているものですか?

このような他の状況では、データ構造を単一のチャネルの背後に配置し、全員が更新を送信しました。そして、データ構造は、ウィンドウがすべて「リッスン」した更新を「公開」します (イベントを発生させます)。

4

2 に答える 2

3

MVC アーキテクチャに似たものを使用するプロジェクトの 1 つに関連する問題があります。中央のデータ構造は次のように参照されます。

-- the data is a tree, and it's kept as a zipper to the current node
Discrete MyDataZip

これは、私のコントローラー宣言の簡素化されたバージョンです。

data Controller st = Controller {
  dState      :: Discrete st
 ,eUpdateZip  :: Event (MyDataZip -> MyDataZip)
 ,eResponse   :: Event (IO ())
 ,bDiagChange :: Behavior (Diagram Cairo R2 -> Diagram Cairo R2)
 }

構築されると、ほとんどのコントローラーは への参照を取得しますがdZip :: Discrete MyDataZip、それを直接変更する方法はありません。コントローラが更新を指定する唯一の方法はeUpdateZip、Controller データ構造内のストリームを使用することです。

複数のコントローラーが 1 つのグラフにまとめられます。これは、存在型のラッパーに配置されたコントローラーの単なるリストですdata EControl = forall st. EControl (Controller st)。個々のパラメータをmconcatすべて取得して、. 新しいコントローラーの作成は純粋であるため、すべてが機能し、同じ let バインディングで実行でき、再帰参照が可能になります。eUpdateZipEvent (MyDataZip -> MyDataZip)Discrete MyDataZip

新しいウィンドウを開くなどの IO タスクはeResponseストリームで行われ、同様にmconcatd されてから に渡されreactimateます。

詳細については、darcs リポジトリを調べることができます。「src/Jaek/UI/Controllers/」および「src/Jaek/UI/ControlGraph.hs」を参照してください。

編集: 中心的な問題は、1 つの大きなネットワークが開発者の視点からはかなり扱いにくいことです。ネットワークをセグメント化することで複雑さを軽減できますが、これは優れたソリューションです。私の設計では、リアクティブな参加者を特定のコントローラー モデルに適合させ、それらのモデルが相互作用するための明確に定義された手段を作成することで、ネットワークに多くの構造を導入しました。私のコントローラーは永続的であるため、すべて静的にセットアップされますが、動的に行うこともできます。その場合、おそらくコントローラーマネージャーを 1 つのスレッドで実行し、新しいコントローラーを生成するアクション (新しいウィンドウを開くなど) は、新しいコントローラーを作成するスレッドへのメッセージ。

于 2011-10-28T11:34:00.620 に答える