Ticket #4 (new enhancement)
Opened 6 years ago
Work with DataProxy, DataReader, and Store subclasses
|Reported by:||tschaub||Owned by:|
Read the Ext docs on DataProxy, DataReader, and Store (and understand Records). Start with DataProxy.
A DataProxy retrieves "unformatted" data objects. Think of fetching a GML doc. In OpenLayers, the Protocol subclasses structure the communication between client and server. Camptocamp has contributed a ProtocolProxy to GeoExt. This is a specific DataProxy that is configured with an instance of an OpenLayers Protocol.
In the end, a user would configure a WFSFeatureStore with the WFS endpoint URL. A DescribeFeatureType request would be issued, and upon its return a GetFeature request would go out. Finally, the store would be populated with records representing the OpenLayers features. Give the store a filter (OpenLayers.Filter) and this gets passed all the way to the WFS protocol (note this should be named ogcFilter or something so as not to conflict with the store's filter method - differentiating between server side and client side filtering).
The DataReader subclasses read data (a reader is sent to DataProxy load) and create objects with Ext.Record objects and associated metadata. In OpenLayers, Protocol objects are constructed with a Format object. So, you will typically have something like a WFS protocol with a WFST format (WFST is weird, but necessary - it mixes the GML and Filter formats and includes readers/writers for wfs transactions). A GeoExt.data.ProtocolProxy could be configured with a WFS protocol (this by default gets the appropriate OL.Format). Calling load on the protocol proxy triggers the protocol read. When the protocol read completes, the format parses the response and returns a list of OL features. The features are still "unstructured" to Ext. So, calling the ProtocolProxy's load method with a FeatureReader instance will result in the generation of Ext.data.Record objects representing those features.
Once you have records, these can be used in an Ext.Store. The store maintains the client side cache of records and is used by components such as ComboBox, GridPanel, and DataView.
Understand the roles of Ext.data.DataProxy, Ext.data.DataReader, and Ext.data.Store - especially with respect to OpenLayers.Protocol, OpenLayers.Format, and OpenLayers.Feature.Vector. Create a store (doesn't need to be a subclass at first, just configure an Ext.data.Store) with a ProtocolProxy that uses the WFS protocol. Give the store a FeatureReader. You should be able to retrieve records representing features in a WFS GetFeature request.
The FeatureReader can be made to understand the feature schema in a couple ways. The second arg to the constructor is a recordType object. See the Ext docs for Ext.data.Record.create. The array of field definitions given to .create can be used as the recordType argument for a FeatureReader (or any DataReader).
So, the recordType array (field definitions) can be created by hand (configured in the application) or they can be fetched from a remote schema. For the styler app, I created an AttributesReader. This deals with the output from calling read on an OpenLayers.Format.WFSDescribeFeatureType object. As a convenience, the AttributesStore provides a store configured with an Ext.data.HttpProxy object and an AttributesReader. So, if you create an AttributesStore with the url for a DescribeFeatureType response, you should get that store populated with a bunch of records - each record representing one of the feature attributes (name, type). This is a representation of the schema.
Ideally (this is where it gets twisted), we could have a WFSFeatureStore (or something). This would provide a convenient way to request and cache schema before load is called on a ProtocolProxy configured with a WFS format. The AttributesStore could be used to return records representing the schema. These records, in turn, would be used to create the field definitions (recordType argument) for the FeatureReader superclass.