gwt-openlayers-devl

[Gwt-openlayers-devl] WFSProtocolOptions

[Edwin C. <com...@gm...>]

Hi Dave,

When looking at the WFSProtocolOptions I was expecting to see methods
for setting a Url etc, but it only had a method to setGeometryName
method.

Am I missing something? Is this an old version of WFSProtocolOptions,
or do you set properties on the options object via JSObject?

Greetings,
Edwin

Re: [Gwt-openlayers-devl] WFSProtocolOptions

[Edwin C. <com...@gm...>]

Hi Dave,

Thanks for your explanation.

The constructor approach is fine! Smart indeed to use to fromWMSLayer
to save coding.

If you're okay with that I will expand the WFSProtocolOptions with
more setters (setURL, setFeatureType, setFeatureNS etc).

Greetings,
Edwin

On 23 February 2010 22:09, Dave Koberstein <da...@ko...> wrote:
> Hi Edwin,
>
> I totally relied on openlayers Protocol.WFS.fromWMSLayer constructor.  It's
> a convenience method where if your GetFeature control is attached to a WMS
> layer and WFS exists at the same service as WMS, then it just builds up a
> protocol for you automatically.  It maps very nicely into the typical
> geosever implementation and saves a ton of coding.
>
> I did the implementation right in the constructor since a separate method of
> the somewhat-obscure name seemed less useful.  There's a WFSProtocol
> constructor (the second one) that takes a WMS layer as well as an options
> object.  That calls a WFSProtocolImpl.create that takes the Layer.WMS object
> and the options object and does the construction with the javascript
> fromWMSLayer.
>
> I know this deviates from your approach of 1-1 mapping.  My thinking was to
> use Java's polymorphism on the constructor to make it simpler to understand
> - pass in your layer at construction time.
>
> Anyway back to why only setGeometryName.  fromWMSLayer uses some default
> geometry name (not from the layer) that doesn't match with geoserver (or
> maybe our team's use of geoserver - I'm not sure).  After construction any
> of the protocol parameters can be overridden and I needed this one.  I
> didn't go through and add all the others as I wasn't in a position to
> confirm any of it worked.  Now that I look at it, I should have added the
> getter.  I'll plan to do that.
>
> If you'd prefer the more 1-1 approach we can adjust it.  If you don't mind
> I'd like to keep this constructor implementation, though.  Also I can add
> more setters and getters WFSProtocolOptions with the caveat that I may not
> be able to thoroughly test.
>
> Davek
>
> On 2/23/2010 12:42 PM, Edwin Commandeur wrote:
>
> Hi Dave,
>
> When looking at the WFSProtocolOptions I was expecting to see methods
> for setting a Url etc, but it only had a method to setGeometryName
> method.
>
> Am I missing something? Is this an old version of WFSProtocolOptions,
> or do you set properties on the options object via JSObject?
>
> Greetings,
> Edwin
>
>
> --
> ________________________________
> Dave Koberstein
> Experienced head of open source technologies,
> VP of Product Line Management, Customer Engineering Services
> email:
> phone:
> da...@ko...
> +1-650-575-3853

Re: [Gwt-openlayers-devl] WFSProtocolOptions

[Edwin C. <com...@gm...>]

Hi Dave,

Just to get this correct: the getGeometryName should be a method on
WFSProtocol, and not on WFSProtocolOptions, isn't it?

I haven't used the GetFeature. Currently, I am not on any GWT
projects, so I work on GWT-OL out of pure interest and to keep
up-to-date with developments in GWT.

Greetings,
Edwin


On 23 February 2010 22:51, Dave Koberstein <da...@ko...> wrote:
> Oh definitely - please do. Would you mind adding a getter for geometryName?
> That will save on hg conflicts.
>
> I don't know if you plan to use the GetFeature control.  Are you using
> geoserver?  I wonder if you've come across this annoyance.  If you make a
> layer group in geoserver of two vector layers, it does not let you make WFS
> feature requests on that layer group.   You have to request from the
> individual layers.  If makes sense if the vector layers are different types
> of data classes.  But if they are the same, it would be nice if it didn't
> impose that limitation.
>
> The constructor approach for WFSProtocol supports this (doesn't matter which
> layer your use in the constructor) however now the browser code needs to
> know what layers the layer group is made of.  I hate constants and
> configuration values.  :)
>
> Davek
>
> On 2/23/2010 1:36 PM, Edwin Commandeur wrote:
>
> Hi Dave,
>
> Thanks for your explanation.
>
> The constructor approach is fine! Smart indeed to use to fromWMSLayer
> to save coding.
>
> If you're okay with that I will expand the WFSProtocolOptions with
> more setters (setURL, setFeatureType, setFeatureNS etc).
>
> Greetings,
> Edwin
>
> On 23 February 2010 22:09, Dave Koberstein <da...@ko...> wrote:
>
>
> Hi Edwin,
>
> I totally relied on openlayers Protocol.WFS.fromWMSLayer constructor.  It's
> a convenience method where if your GetFeature control is attached to a WMS
> layer and WFS exists at the same service as WMS, then it just builds up a
> protocol for you automatically.  It maps very nicely into the typical
> geosever implementation and saves a ton of coding.
>
> I did the implementation right in the constructor since a separate method of
> the somewhat-obscure name seemed less useful.  There's a WFSProtocol
> constructor (the second one) that takes a WMS layer as well as an options
> object.  That calls a WFSProtocolImpl.create that takes the Layer.WMS object
> and the options object and does the construction with the javascript
> fromWMSLayer.
>
> I know this deviates from your approach of 1-1 mapping.  My thinking was to
> use Java's polymorphism on the constructor to make it simpler to understand
> - pass in your layer at construction time.
>
> Anyway back to why only setGeometryName.  fromWMSLayer uses some default
> geometry name (not from the layer) that doesn't match with geoserver (or
> maybe our team's use of geoserver - I'm not sure).  After construction any
> of the protocol parameters can be overridden and I needed this one.  I
> didn't go through and add all the others as I wasn't in a position to
> confirm any of it worked.  Now that I look at it, I should have added the
> getter.  I'll plan to do that.
>
> If you'd prefer the more 1-1 approach we can adjust it.  If you don't mind
> I'd like to keep this constructor implementation, though.  Also I can add
> more setters and getters WFSProtocolOptions with the caveat that I may not
> be able to thoroughly test.
>
> Davek
>
> On 2/23/2010 12:42 PM, Edwin Commandeur wrote:
>
> Hi Dave,
>
> When looking at the WFSProtocolOptions I was expecting to see methods
> for setting a Url etc, but it only had a method to setGeometryName
> method.
>
> Am I missing something? Is this an old version of WFSProtocolOptions,
> or do you set properties on the options object via JSObject?
>
> Greetings,
> Edwin
>
>
> --
> ________________________________
> Dave Koberstein
> Experienced head of open source technologies,
> VP of Product Line Management, Customer Engineering Services
> email:
> phone:
> da...@ko...
> +1-650-575-3853
>
>
> --
> ________________________________
> Dave Koberstein
> Experienced head of open source technologies,
> VP of Product Line Management, Customer Engineering Services
> email:
> phone:
> da...@ko...
> +1-650-575-3853

Re: [Gwt-openlayers-devl] WFSProtocolOptions

[Edwin C. <com...@gm...>]

Hi Dave,

Why have a getGeometryName on the Options object? The Options objects
typically only have setters, since they are a configuration mechanism.
By passing the options (or config) objects to a constructor (or static
factory method) the properties are transferred to the object taking
the options. That object's properties may be relevant within the
application.

Greetings,
Edwin

On 24 February 2010 16:59, Dave Koberstein <da...@ko...> wrote:
> Hmmm...   No, I think it should be in options.  I may have mistyped.
>
> On 2/24/2010 12:49 AM, Edwin Commandeur wrote:
>
> Hi Dave,
>
> Just to get this correct: the getGeometryName should be a method on
> WFSProtocol, and not on WFSProtocolOptions, isn't it?
>
> I haven't used the GetFeature. Currently, I am not on any GWT
> projects, so I work on GWT-OL out of pure interest and to keep
> up-to-date with developments in GWT.
>
> Greetings,
> Edwin
>
>
> On 23 February 2010 22:51, Dave Koberstein <da...@ko...> wrote:
>
>
> Oh definitely - please do. Would you mind adding a getter for geometryName?
> That will save on hg conflicts.
>
> I don't know if you plan to use the GetFeature control.  Are you using
> geoserver?  I wonder if you've come across this annoyance.  If you make a
> layer group in geoserver of two vector layers, it does not let you make WFS
> feature requests on that layer group.   You have to request from the
> individual layers.  If makes sense if the vector layers are different types
> of data classes.  But if they are the same, it would be nice if it didn't
> impose that limitation.
>
> The constructor approach for WFSProtocol supports this (doesn't matter which
> layer your use in the constructor) however now the browser code needs to
> know what layers the layer group is made of.  I hate constants and
> configuration values.  :)
>
> Davek
>
> On 2/23/2010 1:36 PM, Edwin Commandeur wrote:
>
> Hi Dave,
>
> Thanks for your explanation.
>
> The constructor approach is fine! Smart indeed to use to fromWMSLayer
> to save coding.
>
> If you're okay with that I will expand the WFSProtocolOptions with
> more setters (setURL, setFeatureType, setFeatureNS etc).
>
> Greetings,
> Edwin
>
> On 23 February 2010 22:09, Dave Koberstein <da...@ko...> wrote:
>
>
> Hi Edwin,
>
> I totally relied on openlayers Protocol.WFS.fromWMSLayer constructor.  It's
> a convenience method where if your GetFeature control is attached to a WMS
> layer and WFS exists at the same service as WMS, then it just builds up a
> protocol for you automatically.  It maps very nicely into the typical
> geosever implementation and saves a ton of coding.
>
> I did the implementation right in the constructor since a separate method of
> the somewhat-obscure name seemed less useful.  There's a WFSProtocol
> constructor (the second one) that takes a WMS layer as well as an options
> object.  That calls a WFSProtocolImpl.create that takes the Layer.WMS object
> and the options object and does the construction with the javascript
> fromWMSLayer.
>
> I know this deviates from your approach of 1-1 mapping.  My thinking was to
> use Java's polymorphism on the constructor to make it simpler to understand
> - pass in your layer at construction time.
>
> Anyway back to why only setGeometryName.  fromWMSLayer uses some default
> geometry name (not from the layer) that doesn't match with geoserver (or
> maybe our team's use of geoserver - I'm not sure).  After construction any
> of the protocol parameters can be overridden and I needed this one.  I
> didn't go through and add all the others as I wasn't in a position to
> confirm any of it worked.  Now that I look at it, I should have added the
> getter.  I'll plan to do that.
>
> If you'd prefer the more 1-1 approach we can adjust it.  If you don't mind
> I'd like to keep this constructor implementation, though.  Also I can add
> more setters and getters WFSProtocolOptions with the caveat that I may not
> be able to thoroughly test.
>
> Davek
>
> On 2/23/2010 12:42 PM, Edwin Commandeur wrote:
>
> Hi Dave,
>
> When looking at the WFSProtocolOptions I was expecting to see methods
> for setting a Url etc, but it only had a method to setGeometryName
> method.
>
> Am I missing something? Is this an old version of WFSProtocolOptions,
> or do you set properties on the options object via JSObject?
>
> Greetings,
> Edwin
>
>
> --
> ________________________________
> Dave Koberstein
> Experienced head of open source technologies,
> VP of Product Line Management, Customer Engineering Services
> email:
> phone:
> da...@ko...
> +1-650-575-3853
>
>
> --
> ________________________________
> Dave Koberstein
> Experienced head of open source technologies,
> VP of Product Line Management, Customer Engineering Services
> email:
> phone:
> da...@ko...
> +1-650-575-3853
>
>
> --
> ________________________________
> Dave Koberstein
> Experienced head of open source technologies,
> VP of Product Line Management, Customer Engineering Services
> email:
> phone:
> da...@ko...
> +1-650-575-3853

Re: [Gwt-openlayers-devl] WFSProtocolOptions

[Edwin C. <com...@gm...>]

Hi Dave,

Sorry about the confusion. The setGeometryName should definitively be
on WFSProtocolOptions, just as setUrl, setFeatureType,
setFeaturePrefix, and setFeatureNS. Those seem to be all:

http://dev.openlayers.org/releases/OpenLayers-2.8/doc/apidocs/files/OpenLayers/Protocol/WFS/v1-js.html

My point was just that the properties of the Options are copied to the
Object taking the options, so that Object taking the properties should
have the getters. The Options are just a way to pass a lot of
arguments in one go at construction that's why they only have setters.

Greetings,
Edwin


On 24 February 2010 19:41, Dave Koberstein <da...@ko...> wrote:
> Hi Edwin,
>
> Let's separate the getter comment I made from where the setter should go.
>  Perhaps a getter isn't appropriate.
>
> In terms of the setGeometryName being in WFSProtocolOptions, that's the same
> place that featureType, featureNS, etc are.  So I believe that
> setGeometryName belongs there.   I don't think this was your point but if it
> was please let me know why you don't believe geometryName goes there.
>
> In terms of a getter, I guess my thinking is simply that every setter should
> have a getter.  What if you want to know what the current geometryName is?
>  You should be able to call getGeometryName.  Wouldn't the getter go in the
> same class as the setter?
>
> Davek
>
> On 2/24/2010 8:19 AM, Edwin Commandeur wrote:
>>
>> Hi Dave,
>>
>> Why have a getGeometryName on the Options object? The Options objects
>> typically only have setters, since they are a configuration mechanism.
>> By passing the options (or config) objects to a constructor (or static
>> factory method) the properties are transferred to the object taking
>> the options. That object's properties may be relevant within the
>> application.
>>
>> Greetings,
>> Edwin
>>
>> On 24 February 2010 16:59, Dave Koberstein<da...@ko...>  wrote:
>>
>>>
>>> Hmmm...   No, I think it should be in options.  I may have mistyped.
>>>
>>> On 2/24/2010 12:49 AM, Edwin Commandeur wrote:
>>>
>>> Hi Dave,
>>>
>>> Just to get this correct: the getGeometryName should be a method on
>>> WFSProtocol, and not on WFSProtocolOptions, isn't it?
>>>
>>> I haven't used the GetFeature. Currently, I am not on any GWT
>>> projects, so I work on GWT-OL out of pure interest and to keep
>>> up-to-date with developments in GWT.
>>>
>>> Greetings,
>>> Edwin
>>>
>>>
>>> On 23 February 2010 22:51, Dave Koberstein<da...@ko...>  wrote:
>>>
>>>
>>> Oh definitely - please do. Would you mind adding a getter for
>>> geometryName?
>>> That will save on hg conflicts.
>>>
>>> I don't know if you plan to use the GetFeature control.  Are you using
>>> geoserver?  I wonder if you've come across this annoyance.  If you make a
>>> layer group in geoserver of two vector layers, it does not let you make
>>> WFS
>>> feature requests on that layer group.   You have to request from the
>>> individual layers.  If makes sense if the vector layers are different
>>> types
>>> of data classes.  But if they are the same, it would be nice if it didn't
>>> impose that limitation.
>>>
>>> The constructor approach for WFSProtocol supports this (doesn't matter
>>> which
>>> layer your use in the constructor) however now the browser code needs to
>>> know what layers the layer group is made of.  I hate constants and
>>> configuration values.  :)
>>>
>>> Davek
>>>
>>> On 2/23/2010 1:36 PM, Edwin Commandeur wrote:
>>>
>>> Hi Dave,
>>>
>>> Thanks for your explanation.
>>>
>>> The constructor approach is fine! Smart indeed to use to fromWMSLayer
>>> to save coding.
>>>
>>> If you're okay with that I will expand the WFSProtocolOptions with
>>> more setters (setURL, setFeatureType, setFeatureNS etc).
>>>
>>> Greetings,
>>> Edwin
>>>
>>> On 23 February 2010 22:09, Dave Koberstein<da...@ko...>  wrote:
>>>
>>>
>>> Hi Edwin,
>>>
>>> I totally relied on openlayers Protocol.WFS.fromWMSLayer constructor.
>>>  It's
>>> a convenience method where if your GetFeature control is attached to a
>>> WMS
>>> layer and WFS exists at the same service as WMS, then it just builds up a
>>> protocol for you automatically.  It maps very nicely into the typical
>>> geosever implementation and saves a ton of coding.
>>>
>>> I did the implementation right in the constructor since a separate method
>>> of
>>> the somewhat-obscure name seemed less useful.  There's a WFSProtocol
>>> constructor (the second one) that takes a WMS layer as well as an options
>>> object.  That calls a WFSProtocolImpl.create that takes the Layer.WMS
>>> object
>>> and the options object and does the construction with the javascript
>>> fromWMSLayer.
>>>
>>> I know this deviates from your approach of 1-1 mapping.  My thinking was
>>> to
>>> use Java's polymorphism on the constructor to make it simpler to
>>> understand
>>> - pass in your layer at construction time.
>>>
>>> Anyway back to why only setGeometryName.  fromWMSLayer uses some default
>>> geometry name (not from the layer) that doesn't match with geoserver (or
>>> maybe our team's use of geoserver - I'm not sure).  After construction
>>> any
>>> of the protocol parameters can be overridden and I needed this one.  I
>>> didn't go through and add all the others as I wasn't in a position to
>>> confirm any of it worked.  Now that I look at it, I should have added the
>>> getter.  I'll plan to do that.
>>>
>>> If you'd prefer the more 1-1 approach we can adjust it.  If you don't
>>> mind
>>> I'd like to keep this constructor implementation, though.  Also I can add
>>> more setters and getters WFSProtocolOptions with the caveat that I may
>>> not
>>> be able to thoroughly test.
>>>
>>> Davek
>>>
>>> On 2/23/2010 12:42 PM, Edwin Commandeur wrote:
>>>
>>> Hi Dave,
>>>
>>> When looking at the WFSProtocolOptions I was expecting to see methods
>>> for setting a Url etc, but it only had a method to setGeometryName
>>> method.
>>>
>>> Am I missing something? Is this an old version of WFSProtocolOptions,
>>> or do you set properties on the options object via JSObject?
>>>
>>> Greetings,
>>> Edwin
>>>
>>>
>
>

Re: [Gwt-openlayers-devl] WFSProtocolOptions

[Dave K. <da...@ko...>]

I see.  As long as we are consistent, sounds reasonable.

 From a java perspective it might be more intuitive to put the getters 
in the options - with the setters.  I presume the life of the options 
object would be as long as the parent object since it is passed in via 
the constructor.

In either case, the most important thing is to do it consistently.

On 2/25/2010 12:49 PM, Edwin Commandeur wrote:
> Hi Dave,
>
> Sorry about the confusion. The setGeometryName should definitively be
> on WFSProtocolOptions, just as setUrl, setFeatureType,
> setFeaturePrefix, and setFeatureNS. Those seem to be all:
>
> http://dev.openlayers.org/releases/OpenLayers-2.8/doc/apidocs/files/OpenLayers/Protocol/WFS/v1-js.html
>
> My point was just that the properties of the Options are copied to the
> Object taking the options, so that Object taking the properties should
> have the getters. The Options are just a way to pass a lot of
> arguments in one go at construction that's why they only have setters.
>
> Greetings,
> Edwin
>
>
> On 24 February 2010 19:41, Dave Koberstein<da...@ko...>  wrote:
>    
>> Hi Edwin,
>>
>> Let's separate the getter comment I made from where the setter should go.
>>   Perhaps a getter isn't appropriate.
>>
>> In terms of the setGeometryName being in WFSProtocolOptions, that's the same
>> place that featureType, featureNS, etc are.  So I believe that
>> setGeometryName belongs there.   I don't think this was your point but if it
>> was please let me know why you don't believe geometryName goes there.
>>
>> In terms of a getter, I guess my thinking is simply that every setter should
>> have a getter.  What if you want to know what the current geometryName is?
>>   You should be able to call getGeometryName.  Wouldn't the getter go in the
>> same class as the setter?
>>
>> Davek
>>
>> On 2/24/2010 8:19 AM, Edwin Commandeur wrote:
>>      
>>> Hi Dave,
>>>
>>> Why have a getGeometryName on the Options object? The Options objects
>>> typically only have setters, since they are a configuration mechanism.
>>> By passing the options (or config) objects to a constructor (or static
>>> factory method) the properties are transferred to the object taking
>>> the options. That object's properties may be relevant within the
>>> application.
>>>
>>> Greetings,
>>> Edwin
>>>
>>> On 24 February 2010 16:59, Dave Koberstein<da...@ko...>    wrote:
>>>
>>>        
>>>> Hmmm...   No, I think it should be in options.  I may have mistyped.
>>>>
>>>> On 2/24/2010 12:49 AM, Edwin Commandeur wrote:
>>>>
>>>> Hi Dave,
>>>>
>>>> Just to get this correct: the getGeometryName should be a method on
>>>> WFSProtocol, and not on WFSProtocolOptions, isn't it?
>>>>
>>>> I haven't used the GetFeature. Currently, I am not on any GWT
>>>> projects, so I work on GWT-OL out of pure interest and to keep
>>>> up-to-date with developments in GWT.
>>>>
>>>> Greetings,
>>>> Edwin
>>>>
>>>>
>>>> On 23 February 2010 22:51, Dave Koberstein<da...@ko...>    wrote:
>>>>
>>>>
>>>> Oh definitely - please do. Would you mind adding a getter for
>>>> geometryName?
>>>> That will save on hg conflicts.
>>>>
>>>> I don't know if you plan to use the GetFeature control.  Are you using
>>>> geoserver?  I wonder if you've come across this annoyance.  If you make a
>>>> layer group in geoserver of two vector layers, it does not let you make
>>>> WFS
>>>> feature requests on that layer group.   You have to request from the
>>>> individual layers.  If makes sense if the vector layers are different
>>>> types
>>>> of data classes.  But if they are the same, it would be nice if it didn't
>>>> impose that limitation.
>>>>
>>>> The constructor approach for WFSProtocol supports this (doesn't matter
>>>> which
>>>> layer your use in the constructor) however now the browser code needs to
>>>> know what layers the layer group is made of.  I hate constants and
>>>> configuration values.  :)
>>>>
>>>> Davek
>>>>
>>>> On 2/23/2010 1:36 PM, Edwin Commandeur wrote:
>>>>
>>>> Hi Dave,
>>>>
>>>> Thanks for your explanation.
>>>>
>>>> The constructor approach is fine! Smart indeed to use to fromWMSLayer
>>>> to save coding.
>>>>
>>>> If you're okay with that I will expand the WFSProtocolOptions with
>>>> more setters (setURL, setFeatureType, setFeatureNS etc).
>>>>
>>>> Greetings,
>>>> Edwin
>>>>
>>>> On 23 February 2010 22:09, Dave Koberstein<da...@ko...>    wrote:
>>>>
>>>>
>>>> Hi Edwin,
>>>>
>>>> I totally relied on openlayers Protocol.WFS.fromWMSLayer constructor.
>>>>   It's
>>>> a convenience method where if your GetFeature control is attached to a
>>>> WMS
>>>> layer and WFS exists at the same service as WMS, then it just builds up a
>>>> protocol for you automatically.  It maps very nicely into the typical
>>>> geosever implementation and saves a ton of coding.
>>>>
>>>> I did the implementation right in the constructor since a separate method
>>>> of
>>>> the somewhat-obscure name seemed less useful.  There's a WFSProtocol
>>>> constructor (the second one) that takes a WMS layer as well as an options
>>>> object.  That calls a WFSProtocolImpl.create that takes the Layer.WMS
>>>> object
>>>> and the options object and does the construction with the javascript
>>>> fromWMSLayer.
>>>>
>>>> I know this deviates from your approach of 1-1 mapping.  My thinking was
>>>> to
>>>> use Java's polymorphism on the constructor to make it simpler to
>>>> understand
>>>> - pass in your layer at construction time.
>>>>
>>>> Anyway back to why only setGeometryName.  fromWMSLayer uses some default
>>>> geometry name (not from the layer) that doesn't match with geoserver (or
>>>> maybe our team's use of geoserver - I'm not sure).  After construction
>>>> any
>>>> of the protocol parameters can be overridden and I needed this one.  I
>>>> didn't go through and add all the others as I wasn't in a position to
>>>> confirm any of it worked.  Now that I look at it, I should have added the
>>>> getter.  I'll plan to do that.
>>>>
>>>> If you'd prefer the more 1-1 approach we can adjust it.  If you don't
>>>> mind
>>>> I'd like to keep this constructor implementation, though.  Also I can add
>>>> more setters and getters WFSProtocolOptions with the caveat that I may
>>>> not
>>>> be able to thoroughly test.
>>>>
>>>> Davek
>>>>
>>>> On 2/23/2010 12:42 PM, Edwin Commandeur wrote:
>>>>
>>>> Hi Dave,
>>>>
>>>> When looking at the WFSProtocolOptions I was expecting to see methods
>>>> for setting a Url etc, but it only had a method to setGeometryName
>>>> method.
>>>>
>>>> Am I missing something? Is this an old version of WFSProtocolOptions,
>>>> or do you set properties on the options object via JSObject?
>>>>
>>>> Greetings,
>>>> Edwin
>>>>
>>>>
>>>>          
>>
>>