Keeping the list in the loop. Hey, sounds good to me. In any case make sure to run this through the PMC if you plan to incorporate the changes to svn.
Cheers, Gabriel On Wed, Mar 14, 2012 at 8:55 PM, <[email protected]> wrote: > Thanks Gabriel, > > Yes that's right - I'll leave AbstractDataStoreFactory there to prevent any > unnecessary breaks. > > And yes - your description of those relationships is consistent with my > proposal. > > > Adam > > > > -----Original Message----- > From: Gabriel Roldan [mailto:[email protected]] > Sent: Thursday, 15 March 2012 6:28 AM > To: Brown, Adam (CESRE, Kensington) > Cc: [email protected]; [email protected] > Subject: Re: Refactoring 'Factory' hierarchy to accommodate complex features. > Will impact all stores. > > Hi Adam, > > I don't think pulling up some common stuff from > AbstractDataStoreFactory to the new AbstractDataAccessFactory can do > any harm, as long as you're not proposing to remove > AbstractDataStoreFactory. Even if it ended up empty, just in order not > to break binary compatibility with existing code. > > So it would be > - AbsatractDataAccessFactory implements DataAccessFactory > - AbstractDataStoreFactory extends AbstractDataAccessFactory > implements DataStoreFactorySpi > right? > > 2012/3/13 <[email protected]>: >> Hello all, >> >> >> >> Thank you Gabriel and Andrea for your feedback so far. >> >> >> >> I've got the wfs-ng branch and spent some more time looking at the current >> code and trying to work out how to add in a WFS data access factory that >> will support complex features. For your reference, the current hierarchy is >> shown below: >> >> >> >> Current Factory Type Hierarchy (each element extends or implements the >> element above): >> >> (interface) Factory >> >> (interface) DataAccessFactory >> >> (interface) DataStoreFactorySpi (*) >> >> (abstract class) AbstractDataStoreFactory (#) >> >> (class) WFSDataStoreFactory (#) >> >> >> >> * Restriction to simple features starts here >> >> # Has implementation that is useful to both simple features and complex >> features but can only be used for SF as it’s too restrictive >> >> >> >> >> >> I would like to propose the following changes to this hierarchy in order to >> include a WFS factory for Complex features whilst reusing as much code as >> possible and hopefully minimising the number of breaking changes: >> >> >> >> Proposed Factory Type Hierarchy (each element extends or implements the >> element above): >> >> (interface) Factory >> >> (interface) DataAccessFactory >> >> (abstract class) AbstractDataAccessFactory (*) >> >> (class) WFSDataAccessFactory (#) >> >> (class) WFSDataStoreFactory (^) (This still implements DataStoreFactorySpi) >> >> >> >> * A new abstract class, AbstractDataAccessFactory is created and non-simple >> functionality from AbstractDataStoreFactory moves up this class (please see >> note about naming conventions below). AbstractDataStoreFactory remains as an >> implementer of DataAccessFactory and DataStoreFactorySpi but is not used by >> either of the WFS factories. >> >> >> >> # Create new class, WFSDataAccessFactory >> >> >> >> ^ Non-simple functionality from WFSDataStoreFactory moves up to >> WFSDataAccessFactory. WFSDataStoreFactory inherits that functionality and >> can type-restrict is as required. >> >> >> >> >> >> Do you think these changes are acceptable and reasonable given my >> intentions? I should point out that the naming convention I’ve used is that >> anything with DataAccess is a non-restrictive form which means that it’s >> useable with both Complex features and Simple features whereas DataStore >> implies a type-narrowing constraint to Simple features only. Please let me >> know if this assumption is incorrect or if you think that there’s a better >> naming convention I should follow. >> >> >> >> Thanks again for your help. I hope this email is clear but if not, please >> let me know and I will try to explain myself more lucidly. >> >> >> >> Adam Brown >> Software Programmer | CSIRO Earth Science and Resource Engineering >> >> Phone: +61 8 6436 8956 | >> [email protected] | www.csiro.au >> Address: Australian Resources Research Centre, 26 Dick Perry Avenue, >> Kensington WA 6151 >> >> ________________________________________ >> >> From: Gabriel Roldan [[email protected]] >> >> Sent: 09 March 2012 00:28 >> >> To: Andrea Aime >> >> Cc: Adam Brown; [email protected] >> >> Subject: Re: [Geotools-devel] Request approval for changes to: gt-wfs - >> org.geotools.data.wfs - WFSDataStoreFactory.java >> >> >> >> On Thu, Mar 8, 2012 at 12:55 PM, Andrea Aime >> >> <[email protected]> wrote: >> >>> On Thu, Mar 8, 2012 at 4:17 PM, Gabriel Roldan <[email protected]> >>> wrote: >> >>>> Hello Adam, >> >>>> >> >>>> glad to hear you're working on that. >> >>>> >> >>>> Note though that I've been working on a new generation WFS datastore >> >>>> (unfortunately simple features only too), but you might one to join >> >>>> that module instead of hacking on the current one. >> >>>> Work is ongoing on this git branch [1]. It's incomplete though and >> >>>> I'll push to the svn wfs_ng module when it's good enough. In any case, >> >>>> feel free to take a look at it. It should be a better place where to >> >>>> do experimental stuff rather than the current wfs module, as both >> >>>> GeoServer and uDig depend on it. >> >>> >> >>> Mumble... as far as I can see it derives from ContentDataStore, >> >>> >>> https://github.com/groldan/geotools/blob/wfs_ng/modules/unsupported/wfs-ng/src/main/java/org/geotools/data/wfs/impl/WFSContentDataStore.java >> >>> which squarely aims at simple features. >> >>> I guess a new base class would be needed, ContentDataAccess, something >> >>> we don't have today >> >> >> >> Well that's a possibility. Although I wasn't implying to base the >> >> complex-feature capable to be based on the same abstract class, just >> >> calling Adam to collaborate on wfs-ng instead of wfs for the safety of >> >> GeoServer and uDig. >> >> >> >> That said, a ContentDataStore super class that doesn't type narrows to >> >> simplefeature could be something to think about. >> >> Or perhaps just a sibling ContentDataAccess. >> >> >> >> Cheers, >> >> Gabriel >> >>> >> >>> Cheers >> >>> Andrea >> >>> >> >>> -- >> >>> ------------------------------------------------------- >> >>> Ing. Andrea Aime >> >>> GeoSolutions S.A.S. >> >>> Tech lead >> >>> >> >>> Via Poggio alle Viti 1187 >> >>> 55054 Massarosa (LU) >> >>> Italy >> >>> >> >>> phone: +39 0584 962313 >> >>> fax: +39 0584 962313 >> >>> mob: +39 339 8844549 >> >>> >> >>> http://www.geo-solutions.it >> >>> http://geo-solutions.blogspot.com/ >> >>> http://www.youtube.com/user/GeoSolutionsIT >> >>> http://www.linkedin.com/in/andreaaime >> >>> http://twitter.com/geowolf >> >>> >> >>> ------------------------------------------------------- >> >> >> >> >> >> >> >> -- >> >> Gabriel Roldan >> >> OpenGeo - http://opengeo.org >> >> Expert service straight from the developers. >> >> > > > > -- > Gabriel Roldan > OpenGeo - http://opengeo.org > Expert service straight from the developers. -- Gabriel Roldan OpenGeo - http://opengeo.org Expert service straight from the developers. ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure _______________________________________________ GeoTools-Devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
