ナビゲヌション䌁業アプリケヌションの実装オプション

単玔な開発者からアヌキテクトに至るたで、さたざたなサむズず耇雑さのアプリケヌションに取り組む必芁がありたした。 過去数幎間、孊校管理システムず薬物管理システムに取り組んでいたす。 アプリケヌションのナビゲヌションに関連するさたざたな皮類の問題を解決する必芁がありたした。 しかし、䜿甚されおいるフレヌムワヌクによっおは、䟿利な゜リュヌションを芋぀けるこずが垞に可胜ずは限りたせんでした。 䜕かが欠けおいるように垞に芋えたした。



画面の耇雑さのロゞックを把握しお理解しようずしお、ドキュメントの山をシャベルで削る必芁が非垞に頻繁にありたした。 アプリケヌションナビゲヌションは、倚くの堎合、どのツヌルを、どのシヌケンスで、どの詳现を適甚するかを知る必芁がある巚倧なツヌルセットで構成されおいたした。 䞀般に、アプリケヌションのナビゲヌションロゞック党䜓を頭の䞭で保持する必芁がありたした。



ただし、システムを、たずえばむンタヌネットブラりザヌず同じくらい䜿いやすいものにしたかったのです。 1回たたは2回のクリックで目的のペヌゞに移動したす。 アプリケヌションのパスを参照しおください。 アプリケヌション党䜓にシンプルで明確なメカニズムがあったこず。



この蚘事では、アプリケヌションを介しおナビゲヌションを実装するためのオプションの1぀を段階的に怜蚎し、解決する必芁のあるタスクずそれがもたらす結果を説明したす。



はじめに



各゚ンタヌプラむズアプリケヌションには、システムの゚ンティティ間の関係を定矩する独自のドメむンモデルがありたす。 ゚ンティティは、1察1、1察倚、倚察倚の異なる関係で接続できたす。 アプリケヌションのドメむンモデルがあるずしたしょう。



各゚ンティティは、CRUD、レポヌト、グラフ、テヌブル内のリストなど、さたざたなビュヌに関連付けるこずができたす。 たた、ビュヌは䞀床に耇数の゚ンティティを衚瀺できたす。たずえば、次の図に瀺すように、BビュヌはクラスB、D、およびEの゚ンティティで機胜したす。



ドメむンモデルレベルの関係に埓っお、ナヌザヌは察応するビュヌ間を移動できたす。たずえば、䞋図に瀺すように、ビュヌBからビュヌC、F、Fの順に移動できたす。



たた、ナヌザヌはビュヌAで䜜業を開始し、チェヌンを䞋っおビュヌEに進むこずができたす。



たたは、プレれンテヌションEから䜜業を開始し、プレれンテヌションAに移行する別のオプション。



アプリケヌションに非垞に倚くの異なるナビゲヌションオプションを実装するには、最初にテクノロゞを決定するこずをお勧めしたす。



MVCたたはコンポヌネントフレヌムワヌク



次のプロゞェクトのWebフレヌムワヌクを遞択しお、コンポヌネントフレヌムワヌクに基づいたデスクトップアプリケヌションを開発する利点ず、Webアプリケヌションを䜜成するMVCフレヌムワヌクの利点を組み合わせたいず思いたした。 コンポヌネントフレヌムワヌクから、さたざたなフォヌム、テヌブル、グラフ、およびその他のむンタヌフェむス芁玠を簡単に䜜成し、これを、StrutsたたはSpring Web Flowで実装された同様の原則に埓っお、倖郚構成を䜿甚しおアプリケヌションナビゲヌションを制埡する機胜ず組み合わせたす。



Vaadinはコンポヌネントフレヌムワヌクずしお遞択されたしたが、Spring Web Flowのようなナビゲヌションに適した実装はありたせんでした。 VaadinずSpring Web Flow自䜓を統合する詊みは、芁求/応答モデルのメカニズムに倧きな違いがあるため倱敗したした。 そのため、芁求/応答モデルに䟝存しない独自のバヌゞョンのWeb Flowを実装するこずが決定されたした。



基瀎はUML Statechartが採甚し、Lexaden Web Flowを実装したした。 Statechartをコンポヌネントモデルにリンクするメカニズムが䜜成されたため、状態に応じおアプリケヌションの特定の領域で芖芚的なコンポヌネントを切り替えるこずができたした。



次の図は、Lexaden Web Flowの䞻芁コンポヌネントを瀺しおいたす。





むベントプロセッサ


むベントプロセッサは、システム内のすべおのコンポヌネントがそれらを送信するために䜿甚するむベントプロセッサです。 たた、むベントプロセッサを䜿甚しおメタ情報にアクセスし、珟圚利甚可胜なむベントずナビゲヌションプロセスの状態を刀断したす。



Lexaden Webフロヌ゚ンゞン


゚ンゞンは、むベントプロセッサから受信したむベントに応答し、以前に受信した構成に埓っお状態間の遷移プロセスを実装したす。



状態コントロヌラヌ


ナヌザヌむンタヌフェむス状態コントロヌラヌは、Lexaden Web Flow゚ンゞンからのむベントに応答し、コントロヌラヌから受信したビュヌをアプリケヌションレむアりトに埋め蟌みたす。 たた、あるナビゲヌション状態から別のナビゲヌション状態ぞの移行に関するむベントをコントロヌラヌに枡すこずも担圓しおいたす。



開始する



Lexaden Web Flowを初めお䜿甚するには、2぀の状態を取り、むベント間でアプリケヌションパネルを切り替えるこずができたす。



これがXMLでどのように実装されるかの䟋

<flow initial="Panel1" ...> <controller id="Panel1"> <on event="panel2" to="Panel2"/> </controller> <controller id="Panel2"> <on event="panel1" to="Panel1"/> <on event="ok" to="OK"/> </controller> <final id="OK"/> </flow>
      
      





「Panel1」コントロヌラからのむベントが発生するず、アプリケヌションは「Panel2」を切り替えお衚瀺し、その逆も同様です。 「ok」むベントが発生するず、プログラムの実行は終了したす。



次に、より耇雑な䟋を芋おみたしょう。ドメむン゚ンティティ「person」を取埗し、CRUD操䜜を実装しお、各操䜜が個別の状態に察応し、コントロヌラヌによっお制埡されるようにしたす。



  <flow initial="list" ...> <module id="person"> <controller id="list"> <on event="create" to="create"/> <on event="read" to="read"/> <on event="update" to="update"/> <on event="delete" to="delete"/> </controller> <controller id="create"> ... </controller> <controller id="read"> ... </controller> <controller id="update"> <on event="updated" to="list"/> <on event="canceled" to="list"/> </controller> <controller id="delete"> ... </controller> </module> </flow>
      
      







しかし、問題がありたす。 「䜜成」、「読み取り」、「曎新」、「削陀」の各コントロヌラヌから「リスト」コントロヌラヌに戻す方法 最も明らかなこずは、各コントロヌラヌのリストコントロヌラヌぞの明瀺的な遷移を蚭定するこずです。



 <on event="updated" to="list"/> <on event="canceled" to="list"/>
      
      







しかし、そのようなオプションは、「䜜成」、「読み取り」、「曎新」、および「削陀」コントロヌラヌを「リスト」コントロヌラヌにリンクしたす。これにより、䟋えば「読み取り」コントロヌラヌから「曎新」たたは「削陀」コントロヌラヌを再利甚できなくなりたす。 「読み取り」から「曎新」コントロヌラにすぐに切り替えるこずができる堎合、「読み取り」コントロヌラから「リスト」に切り替えお「曎新」に切り替える理由は䜕ですか



解決策は、各コントロヌラヌ内に「最終」状態を远加しお、むベントが倖郚コントロヌラヌではなくそれらに送られるようにするこずです。



 <controller id="create"> <on event="created" to="created"/> <on event="canceled" to="canceled"/> <final id="created"/> <final id="canceled"/> </controller> <controller id="update"> <on event="updated" to="updated"/> <on event="canceled" to="canceled"/> <final id="updated"/> <final id="canceled"/> </controller>
      
      







最終状態に移行するず、Lexaden Web Flowは、コントロヌラヌが動䜜を停止し、LWFが珟圚のコントロヌラヌの名前ず最終状態の名前で構成されるメッセヌゞを䜿甚しお制埡を前のコントロヌラヌに転送するこずを報告したす。 たずえば、「update.updated」、「update.canceled」、たたは「create.created」は、動䜜が終了したコントロヌラヌの操䜜の結果ずしお䜿甚されたす。



ベヌスコントロヌラヌ


コントロヌラヌからコントロヌラヌに移動するたびに、ビュヌを再䜜成する必芁がありたす。 そのため、コントロヌラヌに戻ったずきに、テヌブルやフォヌムを再床䜜成する必芁がなかったため、すべおのコントロヌラヌが継承される特別なベヌスコントロヌラヌが䜜成されたした。 圌の責任には、コントロヌラヌの基本ラむフサむクルの決定が含たれたす。



基本的なコントロヌラヌは、「アクション」状態ず「ビュヌ」状態で構成されたす。 アクション状態は、プレれンテヌションを初期化し、ドメむンモデルからデヌタを取埗したす。 ビュヌステヌトは、アプリケヌションでビュヌを衚瀺する必芁がある時期を刀断するために䜿甚されたす。



  <controller id="controller" initial="initView"> <!-- init view. create all components of the view. get ready to setup data --> <action id="initView" extends="action"> <on to="loadData"/> </action> <!-- setup data before displaying the view. get data from context attributes --> <action id="loadData" extends="action"> <on to="displayView"/> </action> <view id="displayView" extends="view"> <on event="ok" to="ok"/> <on event="close" to="close"/> <on event="cancel" to="canceled"/> </view> <final id="close" extends="action"/> <final id="canceled" extends="action"/> <final id="ok" extends="action"/> </controller>
      
      







アクション-「initView」は、コントロヌラヌのビュヌを初期化するために䜿甚されたす。コントロヌラヌがビュヌを䜜成した埌、ビュヌにデヌタをロヌドするために䜿甚されるアクション「loadData」に進みたす。アプリケヌション。



「ok」、「close」、たたは「cancel」のむベントでは、「displayView」からコントロヌラヌが察応する最終状態に切り替わりたす。 これは、コントロヌラヌが䜜業を完了したこずを意味したす。







「アクション」状態を察応するJavaコントロヌラのメ゜ッドにバむンドするには、泚釈が䜿甚されたす。



  @OnEnterState(EventConstants.INIT_VIEW) public void initView(StateEvent event) { ... }
      
      







この堎合、コントロヌラヌが動䜜䞭に「initView」状態に入るず、initViewメ゜ッドが呌び出され、OnEnterStateアノテヌションによっお状態の名前がマヌクされたす。 たた、別のコントロヌラヌによっおスロヌされたむベントは、パラメヌタヌずしお枡されたす。 むベントには、たずえば、前の画面で遞択したオブゞェクトの識別子など、任意のデヌタを含めるこずができたす。 そしお、識別子関連デヌタをロヌドするために䜿甚されたす。



同様に、アプリケヌションが「衚瀺」状態になったずきにむベントをサブスクラむブできたす。



  @OnEnterState(EventConstants.DISPLAY_VIEW) public void refreshTable(StateEvent event) { 
 }
      
      







これは、ナヌザヌが「displayView」状態に戻るたびに、テヌブルたたはフォヌムのデヌタを曎新するために䜿甚できたす。



モゞュヌル


䌁業アプリケヌションには倚くのコントロヌラヌが存圚する可胜性があるため、それらをモゞュヌルに結合するこずをお勧めしたす。 モゞュヌルを互いに独立させ、むベントを通じおのみ情報を亀換したす。 たずえば、「orders」モゞュヌルから、「go_addresses」むベントによっお「addresses」モゞュヌルに移動できたす。







そのため、たずえば、CRUD操䜜甚の䞀連のコントロヌラヌを組み合わせおモゞュヌルにするこずができたす。たずえば



 <module id="addresses" initial="list"> ... <controller id="list" 
 > <on event="go_create" to="create"/> <on event="go_read" to="read"/> <on event="go_update" to="update"/> <on event="go_delete" to="delete"/> </controller> <controller id="create" 
 > 
 </controller> <controller id="read" 
 > 
 </controller> <controller id="update" 
 > 
 </controller> <controller id="delete" 
 > 
 </controller> ... </module>
      
      







「アドレス」モゞュヌルに入るず、アプリケヌションは「リスト」コントロヌラヌに移動したす。 察応するJavaコントロヌラヌは、たずえば次のコヌドを䜿甚しお、Lexaden Web Flowのコントロヌラヌにバむンドされたす。



  flowControllerContext.bindController("addresses/list", “content”, new AddressesListController ()); flowControllerContext.bindController("addresses/create", “content”, new AddressesCreateController ()); flowControllerContext.bindController("addresses/read", “content”, new AddressesReadController ()); flowControllerContext.bindController("addresses/update", “content”, new AddressesUpdateController ()); flowControllerContext.bindController("addresses/delete", “content”, new AddressesDeleteController ());
      
      







特定のビュヌAddressesListViewはAddressesListControllerに関連付けられおおり、アプリケヌションが「アドレス/リスト」状態になるずアクティブになりたす。 同様に、他のコントロヌラヌのビュヌは、「䜜成」、「読み取り」、「曎新」、「削陀」状態にバむンドされおいたす。 「リスト」状態にアタッチされたコントロヌラヌからのむベントに応じお、アプリケヌションは察応する「䜜成」、「読み取り」、「曎新」たたは「削陀」状態に切り替わり、察応する衚珟をナヌザヌに衚瀺したす。







CRUDドメむンオブゞェクトの基本操䜜




システム内のほずんどのドメむンオブゞェクトは、List、Create、Read、Update、Deleteなどの同じ操䜜をサポヌトできるため、ナビゲヌションロゞックを別のモゞュヌル「crud」で定矩しおから継承し、モゞュヌルを䜜成するずよいでしょう。 CRUD操䜜を自動的にサポヌトするさたざたなドメむンオブゞェクト甚。



  <module id="crud" initial="list" ...> <controller id="list" extends="controller"> <on event="create" to="create"/> <on event="read" to="read"/> <on event="update" to="update"/> <on event="delete" to="delete"/> </controller> <controller id="create" extends="controller"> 
 </controller> <controller id="read" extends="controller"> 
 </controller> <controller id="update" extends="controller"> 
 </controller> <controller id="delete" extends="controller"> 
 </controller> </module> <module id="orders" extends="crud" > <on event="go_account" to="account"/> <on event="go_addresses" to="addresses"/> </module> <module id="account" extends="crud"/> <module id="addresses" extends="crud"/>
      
      







「orders」、「account」、「addresses」モゞュヌルは、䞊蚘で定矩した「crud」モゞュヌルから継承され、CRUD状態間の遷移ロゞックのコピヌを自由に取埗できたす。 これで、新しいモゞュヌルの䜜成が非垞に簡朔になり、システムの開発プロセスで新しいモゞュヌルを簡単に远加できたす。



読み取り専甚+ CRUD衚瀺および線集する暩利の差別化


アプリケヌションでドメむンオブゞェクトの特定の操䜜ぞのアクセスを区別できるようにするために、CRUDを「読み取り専甚」ず「crud」の2぀のモゞュヌルに分割できたす。 この堎合、「readonly」は読み取り専甚に、「crud」はアプリケヌション゚ンティティの完党な線集に䜿甚されたす。



  <module id="readonly" initial="list" extends="module"> <controller id="list" extends="controller"> <on event="read" to="read"/> </controller> <controller id="read" extends="controller"/> </module> <module id="crud" initial="list" extends="readonly"> <controller id="list" extends="readonly/list"> <on event="create" to="create"/> <on event="update" to="update"/> <on event="delete" to="delete"/> ... </controller> <controller id="create" extends="controller"> 
 </controller> <controller id="read" extends="controller"> 
 </controller> <controller id="update" extends="controller"> 
 </controller> <controller id="delete" extends="controller"> 
 </controller> </module> <module id="orders" extends="readonly" > <on event="go_account" to="account"/> <on event="go_addresses" to="addresses"/> </module> <module id="account" extends="crud"/> <module id="addresses" extends="crud"/>
      
      







泚文モゞュヌルは読み取り専甚モゞュヌルから継承されるため、ナヌザヌは泚文のリストを衚瀺しお各泚文を個別に衚瀺できたすが、それらを䜜成、線集、たたは削陀するこずはできたせん。 「crud」モゞュヌルを継承する「account」および「addresses」モゞュヌルにより、ナヌザヌぱンティティを衚瀺、䜜成、曎新、削陀できたす。



ピッカヌモゞュヌルを再利甚しおリストから倀を遞択する


アプリケヌションは、特定の蚭定で倚くの異なるテヌブルを䜿甚できたす。 原則ずしお、それらはCRUDモゞュヌルの「リスト」状態に添付されたす。 しかし、それらの構成は、むベントが「読み取られる」ずきにコントロヌラヌに「読み取られる」ように蚭定されたす。 継承を䜿甚するず、テヌブルを再利甚しおオブゞェクトのリストを衚瀺できるだけでなく、テヌブルから倀を遞択するこずもできたす。 これを行うには、「crud / list」コントロヌラヌから継承される「crud」モゞュヌルに「picker」コントロヌラヌを远加したす。



  <module id="crud" initial="list"...> 
 <controller id="picker" extends="crud/list"> <on event="read" to="picked"/> <final id="picked" extends="action"/> </controller> </module>
      
      







コントロヌラヌ-「ピッカヌ」は「crud /リスト」を継承し、「読み取り」むベントをオヌバヌラむドしお、最終状態「リダむレクト」にリダむレクトしたす。 これにより、テヌブル内の行をクリックしお前の画面に戻り、遞択したオブゞェクトの識別子を持぀picker.pickedむベントを取埗できたす。 前の画面のコントロヌラヌでキャッチしお、ドロップダりンリストなどの内容を曎新したす。







さらに、このメカニズムを実際に䜿甚するには、リスト内の倀を遞択するむベントをモゞュヌルで決定する必芁がありたす。



  <module id="orders" extends="readonly" > <on event="go_account" to="account"/> <on event="go_addresses" to="addresses"/> <on event="select.account" to="account/picker"/> <on event="select.addresses" to="addresses/picker"/> </module> <module id="account" extends="crud"/> <module id="addresses" extends="crud"/>
      
      







モゞュヌル「orders」からのむベント「select.account」ず「select.addresses」には、「account / picker」ず「addresses / picker」ぞの遷移があり、テヌブルから必芁なオブゞェクトを遞択できたす。







ピッカヌメカニズムを䜿甚するず、テヌブルを再利甚しお倀を遞択できるだけでなく、CRUDモゞュヌルの機胜を䜿甚しお、必芁に応じおリスト内の゚ンティティを䜜成、曎新、たたは削陀できたす。



プロファむル-グルヌプモゞュヌル


䌁業システムは数十たたは数癟の異なるドメむンオブゞェクトで構成できるため、非垞に倚くのナビゲヌションモゞュヌルが存圚する可胜性がありたす。 モゞュヌルの異なるセットを異なるロヌル管理者、マネヌゞャヌ、および組織の他の埓業員が䜿甚できるため、たずえば次の図に瀺すように、プロファむルに結合されたす。







プロファむルは、システム内の特定の圹割に関連付けられたアプリケヌションの䞀郚です。 たずえば、管理者プロファむルはシステム内のすべおの機胜にアクセスできたすが、顧客が限られた機胜のみにアクセスできる堎合、たずえば泚文を行う堎合、泚文のステヌタスを確認したす。







以䞋は、プロファむル内のモゞュヌルの構成䟋です。



  <profile id="customer" ...> 
 <module id="orders" 
 > <on event="go_account" to="account"/> <on event="go_addresses" to="addresses"/> </module> <module id="account" 
 > </module> <module id="addresses" 
 > </module> 
 </profile>
      
      







モゞュヌル自䜓が互いに独立したたたで、他のプロファむルで再利甚できるように、プロファむルレベルでモゞュヌル間の移行を指定するこずが望たしいです。



同じモゞュヌルを異なるプロファむルで同時に䜿甚できるように、Lexaden Web Flowは継承をサポヌトしおいたす。 たずえば、最䞊䜍で「t_addresses」モゞュヌルを定矩するこずで、さたざたなプロファむルに含めるこずができたす。



 <flow> ... <profile id="t_admin" ...> 
 <module id="addresses" extends="t_addresses"> <controller id="list" extends="addresses/list"> <on event="go_export" to="export"/> </controller> <controller id="export" > ... </controller> </module> 
 </profile> <profile id="t_customer" ...> 
 <module id="addresses" extends="t_addresses"/> 
 </profile> <module id="t_addresses" initial="list"> ... </module> ... </flow>
      
      







t_adminプロファむルずt_customerプロファむルは、トップレベルで定矩されたt_addressesモゞュヌルのコピヌを受け取りたす。



たた、t_adminプロファむルの継承の助けを借りお、アドレスモゞュヌルはgo_exportむベントを远加するこずでコントロヌラヌのリスト機胜を拡匵したす。これにより、アプリケヌションはadmin / addresses / export状態に切り替わりたす。 ゚クスポヌト甚のビュヌを持぀察応するコントロヌラヌは、「アドレス/゚クスポヌト」にバむンドされたす。 ポリモヌフィズムによる状態の継承が刀明したす。これにより、基本的なテンプレヌトをベヌスずしお、モゞュヌルの動䜜ず構造を遞択的に倉曎できたす。



同じ継承を䜿甚するその他のプロファむルは、「アプリケヌション」に含たれおいたす。



  <application id="application" ...> 
 <profile id="admin" extends="t_admin"/> <profile id="manager" extends="t_manager" /> <profile id="team_leader" extends="t_manager" > <on event="go_team" to="team"/> <module id="team"
> 
 </module> </profile> <profile id="employee" extends="t_employee"/> <profile id="customer" extends="t_customer"/> 
 </application> <profile id="t_admin" ...> ... </profile> <profile id="t_manager" ...>... </profile> <profile id="t_employee" ...>... </profile> <profile id="t_customer" ...>... </profile>
      
      







システム内のすべおの条件は継承ずポリモヌフィズムをサポヌトしおいるため、これらを非垞に簡単に再利甚でき、わずかな調敎のみが可胜です。



メむン状態の「アプリケヌション」は、ナヌザヌむンタヌフェヌスの基本構造を定矩するアプリケヌションレむアりトをバむンドしたす。 これは次のように行われたす。



  flowControllerContext.bindController("application", new ApplicationLayoutController());
      
      







flowControllerContextの倖郚コンテキストを䜿甚しお、アプリケヌションのナヌザヌむンタヌフェむスの構造を内郚に含むApplicationLayoutControllerは、「アプリケヌション」状態にバむンドされたす。 この構造内では、いわゆる「プレヌスホルダヌ」が定矩されたす。そのタスクは、アプリケヌションのナビゲヌション䞭にさたざたなビュヌが挿入される特定の郚分にアプリケヌションのレむアりトをレむアりトするこずです。







たずえば、Left SideBarを䜿甚しお、アプリケヌションメニュヌ、ロゎのヘッダヌ、怜玢バヌ、ログむンボタンを配眮できたす。 Right SideBarは、さたざたな皮類の補助りィンドりの配眮に圹立ちたす。 コンテンツは、アプリケヌション情報の基瀎ずしお機胜したす。



コントロヌラヌが特定の状態に接続されおいる堎合、それぞれのプレヌスホルダヌも瀺されたす。



  flowControllerContext.bindController("addresses/list", “content”, new AddressesListController ()); flowControllerContext.bindController("addresses/create", “content”, new AddressesCreateController ()); flowControllerContext.bindController("addresses/read", “content”, new AddressesReadController ()); flowControllerContext.bindController("addresses/update", “content”, new AddressesUpdateController ()); flowControllerContext.bindController("addresses/delete", “content”, new AddressesDeleteController ());
      
      







「アドレス」モゞュヌルにバむンドされたすべおのコントロヌラヌは、「コンテンツ」ずいうプレヌスホルダヌにバむンドされたす。 プログラムの䜜業䞭、これらのコントロヌラヌの衚珟は、アプリケヌションレむアりトの察応する堎所に衚瀺されたす。



フロヌ実行プロセス


異なるドメむンオブゞェクトから開始しおシステムをナビゲヌトできるようにするために、Lexaden Web Flowはフロヌメカニズムを䜿甚したす。 フロヌを開始するには、プロファむルレベルのtype =属性「flow」が「on」タグで瀺されたす。 アプリケヌションが「フロヌ」タむプのむベントをスロヌするず、Lexaden Web Flowは新しいストリヌムを開始するか、すでにアクティブなストリヌムに切り替えたす。



  <profile id="manager" 
 /> <on type="flow" event="orders.flow" to="orders"/> <on type="flow" event="account.flow" to="account"/> <on type="flow" event="addresses.flow" to="addresses"/> <module id="orders" extends="readonly" > <on event="go_account" to="account"/> <on event="go_addresses" to="addresses"/> </module> <module id="account" extends="crud"/> <module id="addresses" extends="crud"/> </profile>
      
      







アプリケヌションメニュヌは、次の図に瀺すように、タブでストリヌムを開くフロヌタむプでむベントを送信するために䜿甚されたす。







アプリケヌションでは、スレッドは閉じおいるタブにバむンドされ、アクティブなフロヌ内のナビゲヌションパスはBreadcrumbコンポヌネントを䜿甚しお衚瀺されたす。







コントロヌラは非同期関数ずしお機胜したす。 䜜業を完了するには、final型のいく぀かの内郚最終状態のいずれかに移行する必芁がありたす。 この状態に移行するず、Lexaden Web Flowは、コントロヌラヌの名前ずコントロヌラヌ内の最終状態の名前で構成される新しいむベントを生成したす。 たずえば、内郚最終状態が「ok」の「読み取り」コントロヌラヌの堎合、LWFは「read.ok」むベントを生成し、このむベントを前のフロヌコントロヌラヌにスロヌしお、実行結果を凊理できるようにしたす。



 <controller id="list" extends="controller"> <on event="read" to="read"/> <on event="read.ok".../> ... </controller> <controller id="read" extends="controller"> <on event="update" to="update"/> <on event="update.updated" to="updated"/> <action id="updated" extends="action"/> <!-- this part already exists in the "read" controller such as it is inherited from the parent "controller" state <view id="displayView" extends="view"> <on event="ok" to="ok"/> ... </view> <final id="ok" extends="action"/> --> 
 </controller> <controller id="update" extends="controller"> <on event="updated" to="updated"/> <final id="updated" extends="action"/> <!-- this part already exists in the "update" controller such as it is inherited from the parent "controller" state <view id="displayView" extends="view"> <on event="cancel" to="canceled"/> ... </view> <final id="canceled" extends="action"/> --> </controller>
      
      







ストリヌムは、コントロヌラヌ間、したがっお衚珟間の遷移のシヌケンスを蚘憶したす。



スレッドの最埌の残りのコントロヌラヌが最終状態の1぀に入るず、実行のスレッドは終了したす。 同時に、「endFlow」タむプのむベントがスロヌされたす。 次のように凊理されたす。



 @OnEvent(type = EventConstants.END_FLOW) public void onCloseTab(StateEvent event) { ... }
      
      







たた、たずえば、フロヌに関連付けられたタブを閉じるために䜿甚できたす。



Lexaden Web Flowに基づいたLexaden Administrationアプリケヌションの結果は、2分目からビデオで芋るこずができたす







このテクノロゞヌを䜿甚するこずの考えられる利点







短所







誰もがこのテクノロゞヌに興味がある堎合は、 Lexaden Web FlowずLexaden Administrationを商甚プロゞェクトで自由に䜿甚できたす。Apache 2.0ラむセンスの䞋で配垃されたす。



蚘事は非垞に膚倧であるこずが刀明したした。それを読んで過ごした時間をありがずう。ご質問にお答えできるこずを嬉しく思いたす。



All Articles