部品の再利用のイメージ <panel id="aaa"> <piece id="bbb"/> </panel> <panel id="ccc"> <piece id="aaa"/> </panel>名前空間も要るな

モデルが複雑化してきたから、メッセージ通信の仕組みやデータの受け渡しや共有方法についてもうちょい考察が必要になったなー。 プログラミングのテストと並行しながら行うかなー そろそろ手を動かしたいw

ここまでのまとめ → 「CRAPモデルの概要 - いっせいの！！細かなつぶやき」

CRAPモデルについて 概要 オブジェクト指向的概念のMVCをメッセージ駆動概念に置き換える試み。 (C)「コンダクター(conductor)」 メッセージを調整して各ユニットと授受する指揮者 (R) 「レセプター(receptor)」 画面からの入力を受け取りコンダクターに受け…

結局、子コンポーネントのconductorは、親コンポーネントから見たらactorに当たるのか？ 一般的なactorは「入力機能」であるreceptorからの依頼で動くわけだけど、子コンポーネントは自分のreceptorからの依頼で動くから、ちょい趣きが違う。 とはいえ、acto…

コンポーネント対応の件、なんとなく考えがまとまってきた。 コンポーネントと一口に言ってもライトウェイトなモノとヘビーウェイトのモノがある。そこには留意する。 しかしまあ、画面部品のほとんどはライトウェイトなものだ。これらはRAPの全てをメインス…

まあコンポーネントを組み合わせることによるreceptorやperformerの複数化は、conductorとやり取りする部品だけ単一化すれば別に問題ないな。 receptor 1 -+- joint → conductor receptor 2 -+ receptor n -+conductor → joint -+- performer 1 +- performer…

再生産性というか、普通に生産性を考えれば、アプリをスクラッチから作るばかりじゃなく、個別に開発した小さなコンポーネントを組み合わせてより大きなコンポーネントを開発したり、ライブラリーの類いを利用したり出来ないと意味がない。 (画面表示や入力…

一番レスポンスが要求されるであろう、receptor → conductor間の通信と、conductor →performer間の通信を考えると、conductorもメインスレッドに置いて、イベントハンドラにコールバック関数を登録する形にするのが一番コストが低い。 が、conductorはactor…

フレームワークとしてはコンダクター(conductor)が主役だなw コンダクターのAPIの出来が成否を分ける気がする。 成否の基準は、自分のやる気が持つかどうか、だけだけどw とりあえず考えるべきなのは、 レセプター(receptor)が叩くAPI パフォーマー(performe…

汎用性を考えると、同一ドメインの別ウインドウや別タブと協働できる仕組みも必要だな。 今後の課題としてw まあ、この考え方だと、conductor間の通信って形になるよなぁ

ユニットの概要 役割 スレッド 機能 receptor メイン UIによるイベントを受け付けてconductorに渡す performer メイン conductorからの指示によりDOMを操作する conductor WORK 各ユニットから通知を受け取り、調整して、必要な通知を飛ばす actor(s) WORK …

DOMを扱う以上、パフォーマーがメインスレッドになるしか選択肢が無い。 画面入力を受け付けられるのもメインスレッドだけ。 となると、コンダクターはイベント全般を適切に管理するイベントマネージャーに徹するべきかもしれない。 画面入力受け付けは、別…

ブラウザ上でCAPモデルを使うとするじゃん？ シングルタスクで動かすわけないから、workerを使ってマルチスレッド化するじゃん？ CAPモデルでは (C)コンダクター ⇆ (A)アクター (C)コンダクター ⇆ (P)パフォーマー の通信を行うんだから、コンダクターが親に…

私が思うに、まずは分業体制の観点から、入力、内部状態遷移、出力は、完全に分離されなければならない。 また非同期処理について人間が(なるべく)意識せずに済むようにしなければならない。 分業体制を考えるにあたり、 (C)コンダクター 入力機能。(コント…

何度も同じ話するけど、私は、MVC(モデル・ビュー・コントロール)って考え方はしない。 MVCモデルを否定してるわけじゃないよ。 コンピュータの黎明期から、てかその数学的モデルであるチューリング・マシーンにしてからが、「入力 → 内部状態遷移 → 出力」…

ということで、パッと見つけることが出来るような人気のフレームワークで、気にいるものは無かったw 趣味でやるソフト開発なんだから、気に入らないものを使ってストレスをためる必要もない。 まずは自分が気にいるようなフレームワークを自作するところから…

趣味のソフト開発を始めるにあたり、いろんな方面のサイトを見て、いろんなフレームワークを広く浅く調べた。 なんかさぁ、 「どのフレームワークにもオブジェクト主体信仰がはびこっていて生産性を下げてるなー」 「ビュー(に混ざったコントロール)に連結す…