On 26/05/2010, at 7:15 AM, Justin Deoliveira wrote: > While I like the idea of removing the duplication I think the real > problem is in all the FeatureCollection implemetations that lie around > and do something different. I am fine with FeatureCollection duplicating > FeatureSource api as long as it makes it more convenient for the user. > But currently FeatureCollection is meant for direct data access so it > does indeed overlap.
Still the idea of listening to a change to the feature collection? Should that be kept? I just provided to myself that most of the implementations never issued an event. Now I can set them up so they issue an event; or remove that idea. > Can we somehow merge this with the proposal to unify FeatureCollection > into a single implementation wrapped around a FeatureSource? Or is that > a separate beast? Slightly separate; looks like we will end up with two. One wrapped around a getReader( Query ) method and one wrapped around an Iterator. Jody > > On 10-05-25 7:05 AM, Andrea Aime wrote: >> Jody Garnett ha scritto: >>> As andrea indicated in his last email there is certain amount of hate for >>> the duplication between FeatureSource / FeatureCollection :-) >>> I would like to start stripping abilities out of FeatureCollection in a >>> careful controlled manner. >>> >>> Today I have my first candidate for removal: >>> - addListener(CollectionListener listener) throws NullPointerException >>> - removeListener(CollectionListener listener) throws NullPointerException >>> >>> Reasons: >>> - AbstractFeatureCollection maintains a list of listeners ... but never >>> fires events to them >>> - indeed I can only find one implementation that looks like it works ... >>> ContentFeatureCollection >>> >>> The idea of issuing events here encourages users to keep a feature >>> collection around and modify it; a case where we want to encourage >>> FeatureSource. >> >> (this time answering the right mail) >> Sounds like an improvement to me. +1 >> >> Cheers >> Andrea >> > > > -- > Justin Deoliveira > OpenGeo - http://opengeo.org > Enterprise support for open source geospatial. > > ------------------------------------------------------------------------------ > > _______________________________________________ > Geotools-devel mailing list > Geotools-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-devel ------------------------------------------------------------------------------ _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
