Do you think this is even the preferred way to fill up a combo box or list? In
this case the data I need will not be displayed on the map. Feels a bit weird
having to go through a vector layer in that case.
Bart
Sent from my iPhone
On May 16, 2012, at 4:49 PM, Andreas Hocevar <ahoce...@opengeo.org> wrote:
> Hey Bart,
>
> as already discussed during the sprint, I think using a FeatureStore
> connected to an OpenLayers.Layer.Vector should be the preferred option
> over using a ProtocolProxy. I'm not sure if writers were implemented
> that are connected to the Save strategy, but we also do not have
> writers for the ProtocolProxy.
>
> Would that work in your scenario?
>
> Andreas.
>
> On Wed, May 16, 2012 at 4:34 PM, Bart van den Eijnden
> <bart...@opengeo.org> wrote:
>> Found out that this is not the only issue with sharing code from the data
>> package between Sencha Touch and ExtJS 4.
>>
>> ProtocolProxy inherits from src/data/proxy/Server.js and in Ext JS 4 we have
>> something like:
>>
>> operation.commitRecords(result.records);
>> operation.setCompleted();
>> operation.setSuccessful();
>>
>> whereas in Sencha Touch this reads (so there is no commitRecords function
>> etc. on operation):
>>
>> if (operation.process(action, resultSet, request, response) ===
>> false) {
>> this.fireEvent('exception', this, response, operation);
>> }
>>
>> Should we try and make our data package work with both, or should we give up
>> altogether on sharing code?
>>
>> Thoughts?
>>
>> Best regards,
>> Bart
>>
>> --
>> Bart van den Eijnden
>> OpenGeo - http://opengeo.org
>> Expert service straight from the developers.
>>
>>
>>
>> On May 16, 2012, at 3:45 PM, Bart van den Eijnden wrote:
>>
>> I assumed we would be able to use the data components from GeoExt2 in Sencha
>> Touch. So I attempted to use ProtocolProxy in Sencha Touch.
>>
>> The issue I ran into was that this.protocol was undefined, so the proxy was
>> created in the following way in the store:
>>
>> config: {
>> proxy: {
>> type: 'gx_protocol',
>> protocol: new OpenLayers.Protocol()
>> }
>> }
>>
>> I had to make a change to get this to work (basically I needed to use
>> config):
>>
>> diff --git a/src/GeoExt/data/proxy/Protocol.js
>> b/src/GeoExt/data/proxy/Protocol.js
>> index afd5f62..5b49b9b 100644
>> --- a/src/GeoExt/data/proxy/Protocol.js
>> +++ b/src/GeoExt/data/proxy/Protocol.js
>> @@ -14,11 +14,13 @@ Ext.define('GeoExt.data.proxy.Protocol', {
>> extend: 'Ext.data.proxy.Server',
>> alias: 'proxy.gx_protocol',
>>
>> - /**
>> - * @cfg {OpenLayers.Protocol}
>> - * The protocol used to fetch features.
>> - */
>> - protocol: null,
>> + config: {
>> + /**
>> + * @cfg {OpenLayers.Protocol}
>> + * The protocol used to fetch features.
>> + */
>> + protocol: null
>> + },
>>
>> /**
>> * @cfg {Boolean}
>> @@ -79,7 +81,7 @@ Ext.define('GeoExt.data.proxy.Protocol', {
>> Ext.applyIf(options, options.params);
>> delete options.params;
>> }
>> - this.response = this.protocol.read(options);
>> + this.response = this.getProtocol().read(options);
>> },
>>
>> /**
>>
>> Is this to be expected? And does this shed a new light on our use of config
>> in GeoExt2?
>>
>> Best regards,
>> Bart
>>
>> --
>> Bart van den Eijnden
>> OpenGeo - http://opengeo.org
>> Expert service straight from the developers.
>>
>>
>>
>>
>>
>> _______________________________________________
>> Dev mailing list
>> Dev@geoext.org
>> http://www.geoext.org/cgi-bin/mailman/listinfo/dev
>>
>
>
>
> --
> Andreas Hocevar
> OpenGeo - http://opengeo.org/
> Expert service straight from the developers.
_______________________________________________
Dev mailing list
Dev@geoext.org
http://www.geoext.org/cgi-bin/mailman/listinfo/dev
