UIによる自己記述データ

Question

私のチームが10以上のサービスチームからのデータを集約するWeb UIを所有し、より多くの情報を収集するためにそれを顧客に提示する使用例があります。このデータ（json形式）は非常に動的（1日おきに変更）であり、顧客がテキスト、整数、または4〜5のオプションの中からオプションを選択するか、選択して複数のhtmlフォームページを構築するために使用されます。与えられた選択肢の中から複数のオプションなど。このデータは、顧客の地理、性別などによって異なります（各サービスチームによって複数の順列/組み合わせが処理されます）

これらの入力はかなり定期的に変化するので、これらのサービスチームがUIに送信するデータに何らかのスキーマを提供して、UIに次の行のヒントを提供できるオプションを探しています。

有効な入力は何ですか？
ユーザーはどのような種類のデータを入力する必要がありますか？
データのどの部分をテキスト入力としてユーザーに提示する必要があるか、どの部分をオプションとして表示するかなど（さまざまなサービスチームからの入力はjsonデータのリストです）

UIの経験を持つより多くの人々を雇うことは選択肢ではないことに注意してください。データとプレゼンテーションを組み合わせてヒントを提供する標準/先行技術を探しています。問題1と2を解決する、おそらく使用できるjsonスキーマがありますが、問題3は解決しません。

どんな提案/ポインタも非常に役に立ちます。

Kain0_0 · Answer

相互の目的

これは複雑な問題であるため、解決する必要のある問題を明確にするために、次のとおりです。

表示-人間が感知できるようにデータをレンダリングする方法
意図-データの周りでプラットフォームがどのように動作するか
応答-プラットフォームは何を収集し、プラットフォームはそれをどのように処理する必要がありますか。
統合-構成のいくつかのソースの利益を管理する方法。
構成-アプリケーションを調整するために必要なすべてのデータをどのように表現しますか。
コミュニケーションと検証-どのようにしてこれを人間に伝え、それらの人間が正しいことを確認できるようにします。

あなたはおそらくこれらのいくつかを解決しました。ポイント1、2、3を詳しく説明して、ポイント4、5、6の引数を設定します。

表示

これは解決された問題です。MVCとそのバリエーションのいずれでも問題ありません。

有用なバリエーションは大まかに実行されます：

UIはモデル、ビュー、コントローラーで構成されています
モデルはモデルで構成できます。
ビューはビューで構成できます。
コントローラーはコントローラーで構成できます。
ビューは1つのモデルをレンダリングし、そのビューで使用できる相互作用の種類ごとにコントローラー用のスロットを1つ持っています。
モデルは、多くのビューで同時にまたは連続的にレンダリングでき、状態の変化の種類ごとにコントローラー用のスロットが1つあります。
コントローラは、ビューとの相互作用、またはモデルの状態の変化に応じて、モデルとビューに作用します。コントローラーは、イベントに関する顕著な事実を説明するモデルを取り、それを変換して相互作用を実行します。

モデル

特定のタイプのデータを表すためのモデルの小さなセットを定義します。

ブール、整数、テキスト
Xのリスト
X対Yのグラフ

ディスプレイのプリミティブを形成するものの数だけまたは数が少なくなります。可能な場合は、より原始的なモデルの観点からモデルを定義します。

ビュー

データを表示デバイスにレンダリングするためのビューのセットを定義します。目安としては、モデルごとに1対1を使用することをお勧めしますが、モデルがビューを持たない場合や、そのモデルに多数のビューがある場合は、まったく妥当です。

可能な場合は、ビューにサブモデルのレンダリングの責任をサブビューに委任します。ただし、これは、グラフを表（整数サブビューを使用する各セル）と画像形式（線サブビューを使用する系列の整数のリスト）で表示するように、必ずしも意味をなさない。

コントローラ

コントローラには次の3つのタイプがあります。

モデルまたはビューで明確に定義された単一の状態変更を実行するプリミティブコントローラー。
他のコントローラーを構成して、ある種の順次、制御された繰り返し、または選択的な動作を形成する複合コントローラー。
モデルのコピーをビジネスロジックに渡すビジネスコントローラー。

これらは明確かつ簡単に定義する必要があります。

コントローラーに渡されるモデルは、相互作用または状態変化の必要かつ十分な説明であり、詳細を取得するために誰がイベントを生成したかを知る必要はありません。特定のケースでは、ビューやモデルの状態全体のコピーまで、1つまたは2つの値が空になる場合があります。

ビジネスロジックとの相互作用

UIの観点からは、ビジネスロジックは単なる別のユーザーです-描画する必要はありません。それでも、1つまたは複数のビューが必要であると言われています。これにより、読み取り可能なモデルと、ビジネスロジックが実行できる一連のアクションが提供されます。

構成とスキーマ

UIの構成は次のとおりです。

ビュー構成（フォントサイズ、配置、サブビューの構成など）
モデル構成（表示、キャプチャーされる特定のデータ）
コントローラー構成（ビューとの相互作用が他のビューやモデルの状態をどのように変更するかをリンクするため）
ビュー、モデル、コントローラを全体にリンクするための回路図。

明確にするために、構成は多くの有用なデフォルト、または微妙なデフォルトを取得するプロセス、またはユーザーが作成した構成を提供できます。モデル/ビュー/コントローラーの一般的な設定を詳述したテンプレートを利用することもできます。アップストリームサービスの足元にUI仕様のすべての負担を課すことは、問題をアップストリームに移動し、プラットフォームをファンシーUIライブラリ/ Webブラウザーに変えるだけです。

必要な最小構成は、モデルの構成だけです。

意図

これは解決済みの問題でもあります。これはビジネスロジックと呼ばれます。

これは、クライアント、サーバーに存在するか、何らかの方法で分割または共有されている可能性があります。層がどのように構成されていても、特定の動作のモデリングまたは調整を担当するプロセスがあります。構成オブジェクトによって構成されるこれらのプロセスを公開します。

ビジネスレイヤーからの設定を許可する場合は注意が必要です。これは、アプリケーションで他の人のコードを使用する無制限のeval()の形式であるため、かなりのセキュリティリスクを表します。構成オブジェクトは、コードの形式です。

これにより、アプリケーションは、受信したデータに基づいて毎日基本的に異なる動作をすることができます。たとえば、収集した結果を別のサービスに転送したり、UIのユーザーにレポートを送信したりできます。

応答

これは、レンダリングとビジネス行動の調和のとれた関係です。

UIモデルの一部は、人間がビュー、それぞれのモデルに入力するクリック、キープレス、音声などを介して応答を入力できるように構成できるというものです。

次に、ビジネスレイヤーはモデルを受け取り、検証に進み、構成に応じてそのモデルのデータを操作します。

もちろん、単純な応答、直接モデルからテキストへのマッピング、ファイル経由の送信、またはアップロードのみが必要な場合。より複雑なインタラクションとより構成可能なインタラクションが必要な場合は、UIとビジネスロジックレイヤーの構成がより複雑になります。

統合

悪魔はしばしば詳細にあります。アプリケーションは、動作の2つ以上のアップストリーム定義のプラットフォームとして機能しています。どこにでも行くには、彼らがどのように協力するかについて取り組む必要があります。

大騒ぎの答えはまったくありません。各アップストリームサービスは個別に処理されます。ユーザーは、ブラウザーのタブのようにそれぞれのビューを切り替えることができる場合がありますが、それぞれは他のタブとは独立して機能します。

もう1つの極端な例は、Webページのルートです。ページは、潜在的に異なるソースから供給されているサブページに分割されます。各サブページには、その部品を組み立てるための独自のモデル、ビュー、コントローラー、および回路図が含まれています。ページ全体の他の部分によって公開されたビュー（一部はレンダリングされないもの）に影響を与えることで、相互に通信することもできます。他のサブページまたはページ全体に有害な1つのサブページで実行できる多くのアクションがあるため、これは混乱する可能性があります。

真ん中には固い地面があります。ここで、サービスの競合する利益は、明確に定義されたコラボレーションインターフェイスによって制約されます。これらのインターフェイスのサポート数が多いほど、プラットフォームの能力が高くなり、悪意のある人物がプラットフォームを台無しにしてしまう可能性が高くなります。

構成

ビュー、モデル、コントローラー、表示スキーマ、およびビジネスプロセスによって使用される構成オブジェクトの形状がスキーマです。プラットフォームが理解できるものは他にありません。

主な問題は、プラットフォームスキーマを理解していないことです。これは理にかなっています。大規模なアプリケーションはどれも、気が遠くなるようなスキーマを持っています。

私の提案は、自己記述的なデータについて心配することではありません。あなたが知りたいのは：与えられたサービスから、トップレベルの設定オブジェクトは何ですか？

この情報だけでも、そのサービスがプラットフォームとどのように相互作用するかを完全に説明しています。すべてのアップストリームサービスが同じオブジェクトを提供する場合、これは本当に簡単になります。そうでない場合、いくつかの高レベルのエントリポイントが存在します。

トップレベルの構成オブジェクトは、ビジネスプロセスを構成します。ここから、プロセスは、データ形状の定義を含む、その最上位のオブジェクトを解凍する責任があります。各サブ構成オブジェクトは、別のビジネスプロセスに渡されます。それぞれが最上位のオブジェクトをアンパックし、そのオブジェクトを有効にするものを定義し、サブ構成を配布します。

構成オブジェクトの意味を解釈している各プロセスは、警告またはエラー診断とともに各サブ構成の結果を組み立て、副作用なしでそれを渡す責任があります。これらのプロセスはプロセスの有用性を損なうため、副作用を引き起こしてはなりません。理解している間副作用がないため、面倒なクリーンアップ手順なしでエラーを処理でき、理解した構成の状態をテストで検査でき、クリーンなモジュール化が可能になります。理想的には、構成されている正確なタイプは、注入されたファクトリによって隠されます。

返された構成済みの状態が使用可能になる前に副作用が発生する必要がある場合は、activate()または同様のメソッドを結果に追加します。これにより、構成された出力を必要とするプロセスが、それらの副作用が必要かどうか、または検証のみに関心があるかどうかを判断できます。

通信と検証

これで、サードパーティのデータ定義言語を探して見つけたり、プログラムに関係のない不要な検証データを構成に強制したりできます。

Or構成を理解するためのビジネスプロセスはモジュール式に構築されたため、これをライブラリに配置できます。そのライブラリに加えて、複雑なプラットフォームオブジェクトではなく単純なデータオブジェクトを構築するファクトリを、テキストファイルなどを検証する単純なアプリケーションに配置して、予期される構成フォーマットを確認し、エラーが発生した場合に診断を表示できます。

それでも、人間の間で構成形式が何であるかを伝える必要があります。しかし、これは人間にやさしい言語ではるかに人間にやさしいレベルで行うことができます。また、実際の理解（および検証）が使用されているため、人間はモックアップしたデータまたはシステム出力をカスタムバリデーターに送信して、実際のシステムがそれをどのように解釈するかについて、実際の診断を返すことができます。