Re: [Geotools-devel] API Change Proposal: ComplexFeature Parsing & Building Support

[Justin D. <jde...@op...>]

On Wed, Jun 6, 2012 at 7:51 PM, <Ada...@cs...> wrote:

> 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?
>
Cool, if the semantics are different then I think that probably makes sense
to have it be a different name. Can you explain how they are different?

> ****
>
> ** **
>
> 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?****
>
> **
>
Cool, i think that is fine. Ben's message made it sound like you were going
to be making changes to the DataAccessFactory interface itself. But it
sounds like that is not the case.

> **
>
> Thanks again, please let me know if anything is unclear,
>

Good stuff!

> ****
>
> ** **
>
> ** **
>
> Adam Brown****
>
> ** **
>
> *From:* Justin Deoliveira [mailto:jde...@op...]
> *Sent:* Thursday, 7 June 2012 6:16 AM
> *To:* Caradoc-Davies, Ben (CESRE, Kensington)
> *Cc:* geo...@li...; 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...@cs...> 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: Ada...@cs... <Ada...@cs...>
> To: geo...@li...
> <geo...@li...>
>
> 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 |
> ada...@cs...<mailto:ada...@cs...> |
> www.csiro.au<http://www.csiro.au>
> Address: Australian Resources Research Centre, 26 Dick Perry Avenue,
> Kensington WA 6151
>
>
>
> --
> Ben Caradoc-Davies <Ben...@cs...>
> 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
> Geo...@li...
> https://lists.sourceforge.net/lists/listinfo/geotools-devel****
>
>
>
> ****
>
> ** **
>
> --
> Justin Deoliveira****
>
> OpenGeo - http://opengeo.org****
>
> Enterprise support for open source geospatial.****
>
> ** **
>



-- 
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.