4

かなり複雑なデータモデルの要件を持つクライアントがいます。つまり、データモデルは非常に巨大であるだけでなく (約 500 ～ 1000 フィールド、多くのオブジェクトにネストされています)、いつでもすべてのデータを送受信する必要があり、フィールドが常に変更されます (フォーカスを失った後)。すべて JSON として取得します。構造の例を次に示します。

{
    data: {
        somefield: 'some content'
    },
    label: {
        somelabel: 'some label text'
    },
    applyable: {
        somefield: {
            visible: false
        }
    }
    someSubForm: {
        data: {
            somefield: 'some content'
        },
        label: {
            somelabel: 'some label text'
        },
        anotherSubForm: {
            data: {
                somefield: 'some content'
            },
            label: {
                somelabel: 'some label text'
            }
        }
    }
}

しかしそれだけではありません。モデルには、ラベル、ツールチップ、およびその他の構成も含まれています。同じデータが 2 つの異なるタブに表示される可能性がある場合、すべてのデータを複数のタブに表示する必要があります。必要なレイアウト (クライアントによって定義される) により、フォームは互いにネストされます。

バックエンドはお客様から提供されるため、ここでは何も変更できません。

JSON をロードするために、定義済みのプロキシーを持つ単一のモデルを使用することから始めました。しかし、その後、いくつかの問題に遭遇しました。

1 つ目は、ネストされたフォームの 1 つであっても、フォームは常にすべてのフィールドを追跡することです 2 つ目は、ラベルを変更したり、カスタム設定を適用したりできないことです 3 つ目は、大量のデータのために loadRecord() および getValues() メソッドがかなり実行されることです長いです。

私の質問は、各フォームがすべてのデータではなく独自のデータのみを処理するようにこれを分解するにはどうすればよいですか?カスタム設定を適用するにはどうすればよいですか?

4

2 に答える 2

3

これが私が今使っている解決策です：

最初のいくつかの事実:

  1. 複数の R/W 操作をカバーする必要があります (特に、すべてのフィールドが変更されてフォーカスを失った後)。
  2. リクエストごとに常にすべてのデータを取得します
  3. 膨大な量のデータ (フィールド データ、店舗データ、ラベル、構成) をカバーする必要がある
  4. パフォーマンスが重要になるように、この混乱を最適化する必要があります
  5. サーバー側セッションに何かを保存する方法はありません
  6. フォームは互いに乱暴にネストされており、分割されたり、2 度存在したりすることもあります

今のところ私がしていることは次のとおりです。

私はすべての関連付けを削除し、モデルから拡張されたモデルを 1 つだけgetData使用して、カスタム ルート プロパティをサポートする変更されたメソッドを使用することにしsomeSubFormました (質問のサンプル コードを参照してください)。フィールドは auto として構成されているため、リーダーまたはライターへの変更が必要です。堅実ではないかもしれませんが、うまくいきます。

次の大きな問題はフォームです。別のフォームであっても、フォームは常に各フィールドを設定しようとします。さらに、かなり多くのスタンドアロン ラベルを設定する必要があります。デフォルトのフォームが使えないのですが、拡張する必要がありますか？しかし、どのように、どこから始めればよいのでしょうか? ソースをよく見てみると、拡張できないように思われるので、カスタム mixin クラスとカスタム form.basic クラスと共に完全にカスタムのフォーム クラスを作成することにしました。なんで？このフォームに直接配置されたフィールドのみを表示する必要があるため、ラベルを設定してモデル インスタンスをネストされたフォームに渡すことができます。

これで、独自のモニター インスタンスをそれぞれカスタム セレクターに登録できるようになりました。ああ、私は自分の新しいフォームについて最初のことを忘れていました。名前を含むプロパティ ( などsomeSubForm) によってエンティティにバインドされます。

これは、次の場合に使用されます。

  1. アイテムがフォームに追加されます
    • 任意のフィールドが formId を取得します
    • 任意のラベルが formId を取得します (フォームにバインドされたラベルではありません)
    • すべてのフォームはparentFormIdとインスタンスを取得します
  2. モニターセレクターが設定されています
  3. モデルがフォームに読み込まれる
  4. モデルからデータがフェッチされる

2 つ目は、現在 3 つのモニター インスタンスがあることです。

  1. エンティティも検索する新しいセレクターを使用して、すべてのフィールドを収集します。そのため、サブフォーム フィールドは無視されます。これは、独自のエンティティがあるためです。
  2. ラベルも同じ
  3. すべてのフォームを収集

loadRecord3 つ目は、モデルの新しいgetData()メソッドを使用し、特定のデータをフィールド、ラベル、およびモデル全体に​​任意の形式に設定する、修正されたメソッドです。

全体として、これによりパフォーマンスが 800% 向上しました。

于 2013-06-17T07:41:56.343 に答える
2

JSON を分割できないため、Web サービス I/O 用のモノリシック モデルが必要です。これは既に用意されているものです。

ただし、ユーザーがデータを操作しているときは、必要なデータに集中して、読み込みと更新にかかる時間を短縮する必要があります。したがって、各タブまたはタブ内の各フォームをサポートする追加のモデルとストアを定義することをお勧めします。データ サンプルが与えられた場合、たとえば、データをコピーすることによって、大きな I/O モデルが (コールバックで、または load イベントをリッスンして) ロードされた後に作成されるフォーム モデルを作成できます。このコストのかかるコピー操作を、ユーザーがそれぞれのタブを開くまで延期することもできます。

サブフォームがあるようですので、フォームモデル自体に関連付けを追加してみてください。

Ext.define('YourApp.model.FormModel', {
extend: 'Ext.data.Model',
fields: [
    { name: 'data'},
    { name: 'label'}
],
associations: [ {
        type: 'hasMany',
        model: 'YourApp.model.FormModel',
        associationKey: 'someSubForm' 
    }
]
});
于 2013-06-13T08:57:31.547 に答える