Re: [Geotools-devel] WFSDataStore extensions for 1.1.0

[Gabriel <gr...@op...>]

On Thursday 10 January 2008 06:15:39 pm Jody Garnett wrote:
> Gabriel Rold=E1n wrote:
> > If this seems ok, it'd imply moving some stuff around on the wfs plugin,
> > mostly some package refactoring to isolate version specific code from
> > general one. In my opinion it shouldn't be a problem as its the DataSto=
re
> > nature not to be API, and the only public class should be the datastore
> > factory.
>
> This is the same approach we took for OWS-3 you can find an example of
> how to subclass WFS1.0 datastore
> and override just enough methods for GML3 parsing.
>
> The code is still available in svn here:
> - http://svn.geotools.org/udig/branches/ows3/gt/owswfs/
>
> While you are there see if you can make a public method for
> getCapabilities() it is one of the main reasons we still
> subclass WFSDataStore in uDig :-)
cool, will do.
>
> This may be obvious but the approach to take is make a strictly 1.0
> datastore and a 1.1 specific datastore and let the
> WFSDataStoreFactory do the version negotiation in order to choose the
> correct version. You will find ShapefileDataStoreFactory
> takes the same approach when choosing between ShapefileDataStore and
> IndexedShapefileDataStore.
nice, that's exactly what I'm doing. In fact the factory grabs the=20
capabilities and the passes the WFSCapabilities object to the DataStore. Th=
is=20
is a better separation of concerns than having the datastore fetching the=20
capabilities on its constructor, and is unit test friendly too.

Thanks for the feedback. I'll wait until tomorrow to start committing thoug=
h,=20
in case someone else has objections on moving stuff around.

Cheers,

Gabriel
>
> Cheers,
> Jody
>
> !DSPAM:4045,478652c3115422092453641!