Dosといけないこと：Webdynproコンテキスト。

これらのルールはパフォーマンス向上を目的としているように見えます。

私はこれらのルールのカップルについていくつかの発言をしています:

• 必要に応じて、ビュー

などのローカルコンテキストを作成します。 複数のビューで共有されているコンテキストノードがある場合は、コンポーネントコントローラにノードを作成し、他のビューにマップする必要があります。

特定のビューに固有のノードは、ビューコンテキスト上に直接作成することができますが、可読性と均一性のために、すべてのコンテキストノードを集中化し、

• ネスト(マスター詳細)が必要な場合は、シングルトンノードを使用してください

シングルトンノードは、各(非アクティブな)親オブジェクトに複数のインスタン ただし、複数のアクティブな親要素（row repeater、nested tables、trees、multiselection tables）が必要な状況になった場合は、何をしているのかをよく知っていることをお勧めします。..)シングルトンノードはアプリケーションをダンプします。

シングルトンノードの原理がよくわからない場合、またはパフォーマンスが問題でない場合は、シングルトンノードを使用しないでください。

• 動的属性を使用しない(IF_WD_CONTEXT_NODE_INFO->ADD_ATTRIBUTE)

静的に定義されたコンテキスト属性を使用できる場合は、静的属性を使用します。 ただし、コンテキストを動的に作成する必要がある状況があります。 そのような場合は、動的属性を追加する以外に選択肢はありません。 ただし、動的コンテキストプログラミング（および動的ビュープログラミング）を可能な限り避ける必要があることに同意します。

• bind_TABLE

のコンテキスト構造でデータを使用するハード要件ではなく、内部的には、バインド操作は移動対応を使用し、元のテーブルをシャドウ変数に保持します。 移動対応はパフォーマンスには悪いと伝えられていますが。 （私は自分自身のテストを行っており、有意な違いを見つけることができなかったので、私は伝えて言います)

• データを実際に更新する必要がある場合にのみコンテキストを更新します

更新とはどういう意味ですか？

• 長いコンテキストマッピングチェーンは作成しないでください。

?

• ユーザー入力を検出するには、コンテキスト変更ログ関数を使用します。 アプリケーションのユーザーは、大量の混合データを表示しながら、ビュー内の少量のデータのみを変更しますが、これには特別なパフォーマンス上の利点があ

Context changelogは、動的な方法で使用すると非常に強力になります。

しかし、それはまた非常に高度です。 コンテキスト内のすべての変更を実行し、データをassistanceクラスの適切な変数（構造体のフィールド、または内部テーブルの行のフィールド）に割り当て、ハンドラーメ 私はこのスニペットを多くの高度に熟練した開発者と共有しました。 これまで、実際にそれが何をしたのかを理解していたのは2人だけで、自分のコンポーネントに適用することができました。

あなたが言及したルールは十分に興味深いですが、Steveが言及したように、目的と基礎となるアイデアについて詳しく説明することができます。