Hi Justin et al.,
Thanks for your feedback.
I could change append(...) to add(...) but I wouldn't be able to raise it to
the superclass (FeatureBuilder<...>) because the signatures are different:
append(Name, Property) and add(Object). So we would just have two different
add(...) methods in each of the subclasses - is this what you had in mind? I
guess the reason for using append(...) was to make it clear that it is not
related to add(...) and is slightly different semantically. I'm happy to change
it though if that would be preferable?
I included the type hierarchy changes to show how I intended to introduce the
WFSDataAccessFactory. It's not so much an API change because
WFSDataStoreFactory's interface hasn't changed at all but it's ancestry has --
it no longer inherits from AbstractDataStoreFactory (instead, that
implementation detail comes from AbstractDataAccessFactory). That would
potentially break code that tried to use or interact with a WFSDataStoreFactory
as an AbstractDataStoreFactory, such as:
AbstractDataStoreFactory factory = new WFSDataStoreFactory(...)
I don't know if this going to be a problem - it still implements
DataStoreFactorySpi which, I think, is the important part?
Thanks again, please let me know if anything is unclear,
Adam Brown
From: Justin Deoliveira [mailto:jdeol...@opengeo.org]
Sent: Thursday, 7 June 2012 6:16 AM
To: Caradoc-Davies, Ben (CESRE, Kensington)
Cc: geotools-devel@lists.sourceforge.net; Brown, Adam (CESRE, Kensington)
Subject: Re: [Geotools-devel] API Change Proposal: ComplexFeature Parsing &
Building Support
QUickly looked over the proposal and have a few thoughts.
* ComplexFeatureBuilder.append() -> is there no way to keep the method "add()"
like in simple feature builder?
* I don't see how the DataAccessFactory / DataStoreFactory apis are changing?
On Tue, Jun 5, 2012 at 9:32 PM, Ben Caradoc-Davies
<ben.caradoc-dav...@csiro.au<mailto:ben.caradoc-dav...@csiro.au>> wrote:
I would like to note that this proposal is for significant API changes
including refactoring of the Data*Factory*, GetFeatureParser, and
SimpleFeatureBuilder hierarchies (amongst others). I have changed the
title of this thread to emphasise this. Adam's proposal maintains
backwards compatibility, but this could be defeated with sufficiently
clever use of instanceof.
Also, Adam has created some lovely before-and-after UML diagrams in
support of this proposal:
https://www.seegrid.csiro.au/wiki/ASRDC/ChangedTypeHierarchies
Do we as a matter of policy require this external content to be copied
to Codehaus Confluence, or is it OK to leave it on the seegrid wiki?
Kind regards,
Ben.
-------- Original Message --------
Subject: [Geotools-devel] ComplexFeature Parsing & Building Support
Date: Tue, 5 Jun 2012 09:06:12 +0800
From: adam.br...@csiro.au <adam.br...@csiro.au>
To:
geotools-devel@lists.sourceforge.net<mailto:geotools-devel@lists.sourceforge.net>
<geotools-devel@lists.sourceforge.net<mailto:geotools-devel@lists.sourceforge.net>>
Hi all,
I want to add support for complex feature parsing to GeoTools.
It will involve some new API additions hence I'm following the change
proposal guide.
http://jira.codehaus.org/browse/GEOT-4147
http://docs.codehaus.org/pages/viewpage.action?pageId=229736622
This will involve the introduction of a new API for making and handling
complex feature requests but it will be closely aligned with the
existing API for simple features.
I'd like to invite members of the community to review the proposal and
offer any feedback and/or advice as you see fit. I plan on updating this
documentation pending feedback and throughout the development process.
Thanks in advance,
Adam Brown
Software Programmer | CSIRO Earth Science and Resource Engineering
Phone: +61 8 6436 8956<tel:%2B61%208%206436%208956> |
adam.br...@csiro.au<mailto:adam.br...@csiro.au<mailto:adam.br...@csiro.au>> |
www.csiro.au<http://www.csiro.au><http://www.csiro.au>
Address: Australian Resources Research Centre, 26 Dick Perry Avenue,
Kensington WA 6151
--
Ben Caradoc-Davies <ben.caradoc-dav...@csiro.au>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net<mailto:GeoTools-Devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/geotools-devel
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
