メイトフレックスフレームワークの例

上記のフレームワークの誕生直後に、私はこれがまさに長い間欠けていたものであることに気付きました。 私は、CairngormまたはPureMVCフレームワークを使用して膨大な数のクラスを作成するという束縛に本当に入りたくはありませんでした。



一部の同僚は、 Mateを実際に使用することの詳細とニュアンスを常に見つけようと努力しており、この点で、実際のアプリケーションのモデルに基づいた典型的なアーキテクチャソリューションの例を説明することにしました。 フレームワークサイトの例に似ていますが、すべてのレベルで特定の推奨事項が段階的に描かれています。





そこで、入手可能なソースを使用して、 Google Codeでプロジェクトの 機会 （いわば、非常に有望）を準備しました。 まず、 オンラインで検討してください：







各エンティティを個別のフォームで編集し、新しいエンティティを追加する機能を持つエンティティのリストがあります-これは簡単なことではありません。 次のソリューションは、このような例ではいつも不合理に複雑に思えますが、アクションスクリプトの25行で例を書くのではなく、 Mateに慣れるというタスクに直面することは忘れられません。



私は、いわゆる「モデルとインジェクションによる双方向通信」スキームを使用しています。フレームワークのWebサイトには、この手法や他の手法の優れた図があります。







例のクラスに基づいて、ダイアグラムの各要素を考えてみましょう。 サーバーへのアクセスには、 ServiceBaseから継承したOpportunitiesMockServiceの特別なクラスを使用するため、 条項 3を除外します。

モデル

3つのモデルクラスを定義しました。 OpportunityVOリストアイテムの最も基本的なビュー固有のクラス。 2番目のクラスOpportunitiesDataProviderはOpportunityVOのインスタンスのリストであり、サーバーメソッドの呼び出しをカプセル化し、便宜上ArrayCollectionから継承します。 これにより、Flexフレームワークのほとんどのリストコンポーネントのデータプロバイダーとして使用できます。



3番目はOpportunityDataProviderで、リストから特定の編集可能なOpportunityVOと連携するように設計されています。 パブリックプロパティの機会と 、それを操作するメソッドがあります。 このクラスは、DataProviderEventタイプの機会作成イベントと機会保存イベントをディスパッチします。これらのイベントは、機会処理の完了を通知します（これらのアクションはサーバーメソッドの呼び出しに関連付けられることが多いため、クラスメソッド呼び出しストリームで同期的に実行されることは期待できません）。 クラスの実装は非常に単純ですが、実際には、プレゼンテーションのロジックに関係のない、要素のすべての変換、初期化、およびその他のプロシージャをその中に配置する必要があり、非常に簡単に分離できます。







また、ビューに現在表示されているフォームに関する情報を格納するために使用される補助クラスOpportunityViewStateもあります。 Mateのコミュニケーションのニュアンスを解決するために、このようなクラスを作成する必要があります。次に、それらを詳細に説明します。

表示する

プレゼンテーション用に3つのクラスも定義されています。最初のクラスは、アイテムのリストを表示するOpportunitiesListViewです。 1つのパブリックプロパティdataProviderがあり 、OpportunityEventタイプの2つのcreateOpportunity イベントとeditOpportunityイベントを送出します 。



OpportunityEditViewの2番目のクラスは、OpportunityVO編集オブジェクトを直接割り当てる必要がある機会プロパティによって定義され、さらにOpportunityEventタイプの他の2つのイベントsaveOpportunityおよびcloseOpportunityをディスパッチします。



3番目- インデックスは、前のものの構成です。 selectedIndexプロパティが使用でき、現在の表示フォームを決定します。







これが私たちの見解です。 ご覧のとおり、そのクラスは標準のFlexフレームワークコンテナーから継承され、モデルデータプロバイダーに依存せず、受動的で、再利用のためのかなり自給自足のコンポーネントのように見えます。これが必要なものです。

合致イベントマップ

モデルとビューをリンクするMateの役割に直接移動しましょう。 このフレームワークのすべての宣言は、いわゆる「イベントマップ」で説明されています 。 これらは、バインダーとFlex Builderのその他すべての便利さをサポートするMXMLファイルです。 プロジェクトが拡大するにつれて、これらのカードは非常に大きく拡大しているため、さまざまなコミュニケーショングループに対して個別のファイルを取得します。 この例には4つあります。



マップの1つであるDataInjectionMapは、ビューとモデルの間の関係を記述し、アプリケーションの起動時に一度だけ実行されます。 これはIoC（制御の反転）パターンの部分的な実装であり、通常とは異なる方法で動作します：必要に応じて、モデルクラスのインスタンスのみを作成し、ビューの作成時に親アプリケーションのイベントをリッスンし、説明されたバインディングを実行します。 InjectorsおよびPropertyInjectorタグを使用した典型的な表記法：

 <Injectors target="{OpportunitiesListView}"> <PropertyInjector targetKey="dataProvider" source="{OpportunitiesDataProvider}" /> </Injectors>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここでは、データがDataGridに格納されるdataProviderプロパティを使用して、OpportunitiesListViewとOpportunitiesDataProviderの間のバインディングベースの関係を定義します。



残り： OpportunitiesEventMap 、 DataProviderEventMap 、 NavigationEventMapは、ビュークラスとモデルクラスの両方からビューのメイト（イベントバス）フィールドでイベントが発生したときに発生するアクションを直接記述します。 たとえば、EventHandlers、MethodInvoker、およびEventAnnouncerタグを使用する表記法：

 <EventHandlers type="{OpportunityEvent.EDIT_OPPORTUNITY}"> <MethodInvoker generator="{OpportunityDataProvider}" method="editOpportunity" arguments="{[event.data]}"/> <EventAnnouncer type="{NavigationEvent.NAVIGATE_EDIT_VIEW}" generator="{NavigationEvent}"/> </EventHandlers>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この式は次のようになります：ビューがeditOpportunityイベントを送出する瞬間（実際には、編集ボタンを押す）、OpportunityDataProviderモデルクラスのインスタンスは、イベントからアクセス可能なOpportunityVOクラスのインスタンスの編集操作を開始する必要があります。



また、特別なNavigationEventイベントが送信され、その結果、ビューは編集モードに切り替わります。 OpportunityDataProviderクラス内で、サーバーメソッドを呼び出して、要素の最後の状態でOpportunityVOインスタンスを取得する必要があります（ただし、この例では、スキームを単純化し、モデルの機会プロパティにモデルを保存しました）。 さらに、機会プロパティによってOpportunityEditViewとOpportunityDataProviderの間のDataInjectionMapで注入を指定したため、編集されたアイテムはビューで使用できます。



上記のタグのジェネレーターまたはソースプロパティでは、このクラスのインスタンスではなく、モデルクラスを示します。 Mateは適切なタイミングでインスタンスを自動的に作成し、デフォルトでは1回だけ作成します。 フレームワークには、あらゆる種類のモデルインスタンスまたはイベント用の内部キャッシュがあり、再利用のために必要なオブジェクトを検索します。 このスキームはシングルトンパターンに似ていますが、 「loners」を使用するときに避けられないシステムエンティティ間に不必要なバインドがないため、はるかに実用的です（ちなみに、 CairngormやPureMVCなどの他のフレームワークにはかなり強い欠点があります ）。



最後に、NavigationEventイベントへの応答を説明するNavigationEventMapマップの詳細を検討します。 一般に、ビューモードの切り替えは、その中に直接実装できます。 しかし、実践が示しているように、大規模なプロジェクトでは、プレゼンテーションの外部制御のアプローチを視覚的に簡単に制御できます。 たとえば、 ディープリンク （ブラウザのアドレスバーの変更のサポート）を有効にする必要がある場合、 Mateマップで既製のアクションリストを使用するBrowserNavigationEventイベントの別のタイプを導入します。 表記法は次のとおりです。

 <EventHandlers type="{NavigationEvent.NAVIGATE_EDIT_VIEW}"> <MethodInvoker generator="{OpportunityViewState}" method="setSelectedIndex" arguments="{[1]}" /> </EventHandlers>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

navigateEditViewイベントがMateにヒットすると、OpportunityViewStateモデルの補助クラスのメソッド（プロキシ）が呼び出されます。 これらの目的のためにこのクラスを導入したくありませんが、Indexビュークラスで直接selectedIndexに値を割り当てますが、MethodInvokerタグのジェネレータープロパティでビジュアルコンポーネントのクラスを指定することはできません（他のすべてのタグと同様）フレームワークは誰にもアクセスできないインスタンスを作成するため、間違っています）。 一番下の行は、上で書いたように、 Mateはビジュアルコンポーネントのインスタンスを作成せず（MXMLは試行しません）、アプリケーション全体のイベントをリッスンし、コンポーネントが Flash Playerの表示リストに入ると、フレームワークが「それと連携し始めます」 「（多くの場合、（ インジェクション ）依存関係を決定するため）。 フレームワーク自体によって作成されたすべてのクラスの内部キャッシュと、Flash Playerが管理し、交差しないコンポーネントの個別のリストがあることがわかります。



以上です。 利用可能なすべてのフレームワークタグに関する情報は、 Mate Webサイトのドキュメントに記載されています 。 説明があまりにも混乱しないようにしたいと思います。 トピックに関する関連するすべての質問に回答させていただきます。



PSところで、 先日 、 Mateバージョン0.8.7の更新がありました。このバージョンでは、インターフェイス間の接続（ インジェクション ）を設定できるようになりました。