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