誰かがコードの作成/更新などのスニペットをどこに書くべきか教えてもらえますか?私はプロキシのapiプロパティの下でそれを書いています。出力を確認する方法。ストアAPIの使用方法を教えてください。
私はテストに取り組んでいるので、機能の理解と使用法をより明確にしてください
誰かがコードの作成/更新などのスニペットをどこに書くべきか教えてもらえますか?私はプロキシのapiプロパティの下でそれを書いています。出力を確認する方法。ストアAPIの使用方法を教えてください。
私はテストに取り組んでいるので、機能の理解と使用法をより明確にしてください
構成自体は、こちらのドキュメントで説明されています。しかし、構文が正しいようです。
最初に知っておくべきことは、この構成は、拡張するプロキシにのみ適用されるということExt.data.proxy.Server
です。こちらの「プロキシの種類」セクションをお読みください。
この構成でさまざまな URL を定義することにより、サーバー側でさまざまな CRUD アクションを実行するために ajax 要求を送信する場所をストアに伝えるだけです。
たとえば、 を呼び出すとstore.load()
ajax リクエストがapi.read
URL に送信されます。この URL がデータを適切に返すようにするのはあなた次第です。
は、「ダーティ」レコードに対して実行されたExt.data.Store
他のアクション (作成、更新、または破棄) を内部的に追跡します。これに基づいて、適切なapi
設定 URL に ajax リクエストを送信します。または、レコードの作成と削除など、さまざまなタイプのアクションを実行した場合、作成または削除したレコードに関するデータとともに、複数の ajax リクエスト (各 URL に 1 つ) が送信されます。
これを説明するためのサンプル コードを次に示します (独自の URL と を入力した場合のテストにも使用できますdata.model
)。この例では、JSON としてサーバーにデータを送信するデフォルトのリーダー/ライターを使用しています (プロキシには別の形式を指定する構成があります)。
var myStore = Ext.create('Ext.data.Store', {
model: 'MyApp.model.SomeModel',
proxy: {
type: 'ajax',
// without api defined ALL ajax calls will use the 'url' config
url: '/some/url',
api: {
create: '/some/url/to/insert/records/in/db',
read: '/some/url/to/select/records/from/db',
update: '/some/url/to/update/records/in/db',
destroy: '/some/url/to/delete/records/in/db'
}
}
}
// this calls the api.read URL
myStore.load();
// assuming we now have records, this will delete the first record
// on the client side (it will error if there are not records)
myStore.remove(myStore.first());
// the store knows we deleted a record so this will call the api.destroy URL
myStore.sync();
// this updates the first record on the client side
myStore.first().set('some_field_name', 'a string value');
// now we are creating a record on the client side
myStore.add(Ext.create('MyApp.model.SomeModel'));
// the store knows we updated AND created a record so this will call the
// api.update URL AND the api.create URL
myStore.sync();
これに関する他の 2 つの有用な情報:
batchActions
docs には、ここで説明されているというプロキシ構成があります。これはtrue
デフォルトです。つまり、データベースにリクエストを送信すると、特定のタイプのすべての CRUD アクションが配列にグループ化されます。たとえば、4 つのレコードを削除した場合、
api.destroy
URL は 4 つの ajax リクエストを受信せず、4 つのレコードの配列を持つ 1 つの ajax リクエストを受信します。これは、アレイを処理するように URL を構成している限り、ネットワーク トラフィックを削減するのに役立ちます。この構成を に設定するfalse
と、ストアはapi.destroy
代わりに URL に 4 つの要求を送信します。ライターの構成allowSingle
(ここで説明) を設定して、レコードが 1 つしかない場合でもすべてのリクエストが配列として送信されるようにすることもできます (そのようにして、サーバー側のコードを設定して常に配列を処理することができます)。
Ext.data.Store
create および update アクションのコールバックを処理するように設定されているため、URL が 1 つを送り返すことを確認するだけで済みます。ストアを呼び出すとmyStore.sync()
、クライアント側のレコードが、コールバックで送信したレコードに自動的に置き換えられます。これは、作成されたレコードと一緒に正しいデータベース ID を送り返し、クライアント側で使用できるようにすることができるため、作成されたレコードに役立ちます。後でユーザーがレコードを編集または削除したい場合は、正しいデータベース ID を使用して作業できます。また、サーバー側で他の処理を行い、他のデータも送り返すことで、完全な記録を残すことができます (たとえば、作成ユーザー ID と作成時間も送り返すことがあります)。