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
>>>
>>>
>
>