ナビゲーション：企業アプリケーションの実装オプション

単純な開発者からアーキテクトに至るまで、さまざまなサイズと複雑さのアプリケーションに取り組む必要がありました。 過去数年間、学校管理システムと薬物管理システムに取り組んでいます。 アプリケーションのナビゲーションに関連するさまざまな種類の問題を解決する必要がありました。 しかし、使用されているフレームワークによっては、便利なソリューションを見つけることが常に可能とは限りませんでした。 何かが欠けているように常に見えました。

画面の複雑さのロジックを把握して理解しようとして、ドキュメントの山をシャベルで削る必要が非常に頻繁にありました。 アプリケーションナビゲーションは、多くの場合、どのツールを、どのシーケンスで、どの詳細を適用するかを知る必要がある巨大なツールセットで構成されていました。 一般に、アプリケーションのナビゲーションロジック全体を頭の中で保持する必要がありました。

ただし、システムを、たとえばインターネットブラウザーと同じくらい使いやすいものにしたかったのです。 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のソースレベルでナビゲーションをデバッグする必要があります
• 小規模なアプリケーションには適していません。
• アプリケーションを介して構成を変更できるビジュアルエディターはありません。
• プログラムのコンパイルの段階でナビゲーションの構文をチェックできるコンパイラはありません
• デモアプリケーションは現在、Vaadinコンポーネントアーキテクチャでのみ使用できますが、Lexaden Web Flowは特定のコンポーネントフレームワークに依存していません。

誰もがこのテクノロジーに興味がある場合は、 Lexaden Web FlowとLexaden Administrationを商用プロジェクトで自由に使用できます。Apache 2.0ライセンスの下で配布されます。

記事は非常に膨大であることが判明しました。それを読んで過ごした時間をありがとう。ご質問にお答えできることを嬉しく思います。