すべての開発者の生活の中で、フォームを作成する必要がある瞬間があります。 それは複雑なもののようです-それを取り、それを落とします。 しかし、いや、形は生きているようなものです。 彼女には彼女自身の気分、習慣があります。 私は床を選びました-「F」、彼女は変形しました、彼女は少し変わって、好奇心が強くなりました、彼女が結婚したかどうか、彼女の好きな香水、かかとのある靴、またはない靴？ しかし、あなたは男です！ そして、フロア「M」を選択します。実際のところ、質問は異なるものでなければなりません-シングル、好きなビール、好きなスポーツ。 もちろん、くしゃみごとにたくさんの型を作ることができます。「M」の場合は1つ、「F」の場合は1つ、もう1つはもう1つです。 しかし、そのような方法はサポート段階で大惨事になり、実際、美しいコードの精神ではありません。 したがって、フォームはスマートでなければなりません。 とても賢い。 彼女は誰が彼女に触れているのか、彼が何を望んでいるのか、彼の秘密の欲望を知っているべきです。 例：5つのフィールドに住所を入力するためのフォームがあります
- 国
- エリア
- 街
- 通り
- メトロ
私は都市を選び、地域と国の形を考えてみませんか？ またはウラジミール地域を選んだのに、なぜ都市のリストに「モスクワ」が必要なのですか？ ウラジミール地域の「メトロ」フィールドも関係ありません。また、ストルニーノの都市が選択されると、一般的にgenerally笑されます。 5年間、企業のWEBアプリケーションでクライアント側の開発に携わってきましたが、フォームをスマートにする方法をまだ知っていました。 私の経験がお役に立てば幸いです。
ERPシステムのフォームの基本要件は次のとおりです。
- データに応じて、フィールドのセットとその属性が変更されます（必須入力、編集可能）。
- 一部のフィールドの値に応じて、他のフィールドの値がフィルタリングされます。
- フォームを入力すると、フィールドの値とその属性を変更できます。
いずれにせよ、これは2つの方法で解決されます。
- マスターによってアーチ形にされた多くの高度に特殊化されたフォーム。
- 多くのイベントで状態を変更するユニバーサルフォーム（少なくとも値を変更する場合）。
最初のケースでは、すべてがかなり悲しくなります。 たとえば、性別による分岐を考えてみましょう。 余分なフィールドでユーザーを困らせないために、まず性別を見つけてから、この選択に関連するフォームを表示します。 どういうわけか次のようになります。
厳密に言えば、この情報収集方法は「マスター」と呼ばれます。 特定の目的には適しています（たとえば、選択後、ユーザーのタスクが変更され、1つのフォームに多くのデータがあるか、フォームが異なるビジネスオブジェクトを反映するかのどちらかです）が、ダイナミクスを与えるためにそれを使用することは行き詰まりです。
原則として、ロジックがすべてのブランチで同一のフィールドがあります。 最も簡単なことは、このロジックを複製することですが、これも最も間違っています。 開発者はすぐに自分のコードに夢中になりますが、設定を通じて構成について話す必要はありません。設定も複製されます。 また、分岐は成長する傾向があり、ツリーは複雑なグラフになる傾向があります。
さまざまなイベントのビューを変更するビジネスオブジェクト（エンティティ）ごとに1つのフォームを持つ方が効率的です。 ここで、2番目の方法が救助に来ます-動的に変化する普遍的なフォーム（分割は条件付きですが、マスターはそのようなフォーム上に構築できます）。 実装は、分岐よりも少し複雑です。 以前は「何が複雑なのか」と考えていましたが、この問題を解決する過程で、熊手、落とし穴、繊細な素材の数は信じられないほど増えていきました。 これらすべてを経験したので、私は自分の痛みと経験を共有せざるを得ません。
ダイナミクス要素
ええと、まあ、そこに何かを隠して、何かを見せて、どこかにフィルターをかけます。 それほど単純ではありません。 まず、管理する主なものが3つあります。
- 可視性
- 義務的
- 在庫状況
アクセシビリティとコミットメントがそれほど明確でない場合、可視性は些細なものではなく、その管理はフィールドの配置方法と密接に関連しています（落とし穴が生じています）。
形而上学的に、フィールドは固定的または相対的に配置できます。 さらに、フィールドの幅などのサイズは、パーセントまたは固定値で指定できます。 単純なルールがあります-固定値と相対値はうまく結合しません。 フォームがゴムであるか、絶対座標で固定されているかをすぐに判断する必要があります。
固定フォーム
フィールドは絶対座標で固定されているため（絶対レイアウトはどこにでもあります）、配置の点で作業が簡単です-整列用のグリッドを作成し、マウスを使用して簡単に好きなようにフィールドを配置します。 フィールドは少なくとも40emである必要がありますが、少なくとも自分自身を殺す必要がありますが、サイズは固定されています-問題はありません、40または40。 可視性管理が始まると問題が始まります。 3つのフィールドがあり、中央のフィールドは隠され、穴は残ります。
この穴を閉じる方法は？ ここで見つけたとしますが、構造がより複雑な場合はどうでしょうか？ 3列の列とフィールドのグループを言う？ このすべてを測定して再集計することはしません。
フォームの寸法と座標が固定されている場合、可視性の動的な制御が最も難しいタスクになります。 スケッチの便利さとシンプルさ、またはすべての利点を備えた動的な可視性のいずれかを、すぐに明確に視覚化して選択する必要があります。
ゴム型
しかし、絶対座標で固定されていないゴムの形はどうでしょうか？ すべてがうまくいきます！ 穴は単純に崩壊します：
折りたたみは、フィールドの可視性を変更する際の主な問題です。 ユーザーは、ボイドではなく、意味に満ちた美しいフォームを見たいと考えています。
この問題は、フォーム上のフィールドのみが少ないときに悪化します。 美しい、巻き毛の形が欲しいです。 いくつかのフィールドの列、表形式の部分があるブックマークバー、グループ化などがあります。
フォームでは、フィールドではないものはすべてコンテナです（このような概念は今のところ検討します）。 また、コンテナにはフィールドが含まれます。 また、フィールドは非表示になる可能性があり、この場合のコンテナーは空になります。 空の容器は、型の穴よりも悪いです。 彼は自分の畑を追って地下に行かなければなりません。 しかし、これは不運です。コンテナをネストしたり、何回もネストしたり、何回もネストしたりすることができます（他の人は私の目には触れません）。 表示フィールドが存在するため、コンテナツリーをバイパスする必要があります。 バイパス、幸いなことに、ダウン。 いずれにしても、フォームは次のように階層化される傾向があります。
アルゴリズムは単純なようです-フィールドの可視性状態を変更し、コンテナを最初の可視フィールドにバイパスしました。 そのようなフィールドを見つけました-basta、コンテナが見えますが、見つかりませんでした-コンテナは隠れているので、親コンテナに対して同じ手順を繰り返します。 これは解決策の1つです。
個々のフィールドではなく、コンテナ全体を非表示にしたい場合もあります。 コンテナの絶対的な非表示のサインが表示されるため、コンテナ内のフィールドが「表示」されていても、コンテナは表示されません。 かなり迅速に、このメカニズムは成長し、より複雑になります。サーバー上、クライアント上、または隣接する場所で、すべてをカウントする場所をすぐに考えた方がよいでしょう。 この場所で責任を共有することは非常に重要です。
そして、ダイナミクスはどこから来ますか？
サーバー（K.O.）から取得されます。 実際、これは、ユーザーがインターフェースを介して設定する（強く望ましい）いくつかのルールのセットです。 最も単純なダイナミクスのブリックは、HELP（フィールド条件値）です。 この式は単純化されています。「フィールドの値が値と等しい場合、フィールドは表示されます。それ以外の場合は表示されません。」 条件は、フォーム上の一部のフィールドの特定の値を標準と比較し、選択した条件に応じて、このHSSが属するフィールドの状態（可視性、アクセシビリティ、必須）を変更します。 たとえば、 このフォームには、「Metro」フィールドが都市にない場合に非表示にするためのヘルプがあります。 ダイナミクスが構築されるのは、このような基本的な条件です。 もちろん、それはPUZ-ahだけではありません。 ドキュメントのステータス、操作で使用可能なフィールド、および多くの恐ろしい単語があります。 しかし、クライアントレベルでは、これはすべて抽象化であり、どこから来たものであるかは関係ありません。それをどのように解決するかが重要です。
HSSがフィールドだけでなくコンテナ全体も管理できることは注目に値します。コンテナはビジネスロジックの要素ではないため、イデオロギー的には議論できますが、多くの場合便利です。
まとめ...
上記の手紙では、フォームのダイナミクスがどのように行われるかについて説明しました。 タスクは非常に簡単で、インターフェイスに使用するコンポーネントに大きく依存します。 これがWeb上でどのように行われるかを説明しましたが、非常に一般的であるため、多くのシステムに適合します。 システム内のフォームのアーキテクチャをどのように考え始めるかを考え始めるとき、すぐに説明したニュアンスについて考える価値があります。
少し後で（関心がある場合）、ダイナミクスのソース、つまりフィールドイベント、動的フィルターについて詳しく説明します。HELDについてさらに詳しく説明し、ステータスと操作について説明します。 これらはすべて、会計システムの一般的なトピックであり、それだけではありません。