Re: [Geotools-devel] Datasources

[Sean G. <se...@sm...>]

Hi Chris.

How about using an adapter class to receive the features from the 
GMLFilterHandler class instead of doing it in the GMLDataSource class.  
This will let you extend AbstractDatasource.

Something like this:

class GMLAdapter extends XMLFilterImpl implements FeatureHandler {
      FeatureCollection fc;

      GMLAdapter(FeatureCollection fc) {
            this.fc = fc;
       }

      public void feature(Feature feature) {
         fc.add(feature);
      }
}

This will free up the GMLDatasource to using the AbstractDatasource 
default implementations and clean up some duplicated code.

Sean


Chris Holmes wrote:

>>A datasource only needs to extend AbtsractDataSource, but some of them 
>>implement DataSource (which is already implemented by 
>>AbstractDataSource).  The GMLDataSource doesn't even extend 
>>AbstractDataSource, just implements DataSource.
>>    
>>
>Yes, gml is a weird one.  I did most of the moves of datasources to 
>extending AbstractDataSource, but didn't change GMLDataSource because it 
>was already extending XMLFilterImpl.  I _think_ the reason for this is so 
>that it can implement GMLFeatureHandler, which is an interface needed to 
>recieve features that are parsed.  That interface extends ContentHandler 
>with the features() method, which is called when features are found in 
>parsing.  XMLFilterImpl is an easy way to fill out the 
>ContentHandlerInterface.  The easiest way for me to resolve it was to just 
>not extend AbstractDataSource.  Perhaps there is a more elegant way using 
>interfaces and abstract classes.  Or a way to rewrite GMLFeatureHandler?  
>I'm not sure.  If you can work out a better way to work the multiple 
>inheritance go for it.  If there was another datasource that used SAX then 
>a root abstract class would definitely make sense, and perhaps may make 
>sense anyways.
>
>  
>
>>Also, it seems to be standard that a datasource follows the packaging 
>>rule org.geotools.data.xxx, but GMLDataSource seems to break that rule 
>>by being in package org.geotools.gml.
>>    
>>
>Gml is also weird here, as the gml package contains a lot of generic tools 
>for reading and writing gml.  They are used by gml datasource, but are 
>also written to be reused by others, such as Filters.  The thing to do may 
>be to have most classes in org.geotools.gml, and then create 
>org.geotools.data.gml and put the datasource class there.
>
>  
>
>>I don't think any of these are major problems, just little things that 
>>need to be corrected before the beta release.
>>    
>>
>Definitely.  The gml module is one with lots of little problems that we 
>don't get around to fixing up because it's pretty complicated and things 
>work well enough.  It could also use unit tests on most of the helper 
>classes.  I'm sure they work, as geoserver uses them on just about every 
>single request, so they've been tested very extensively.  But it would be 
>nice to have better tests in geotools.
>
>
>
>	Chris
>
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: VM Ware
>With VMware you can run multiple operating systems on a single machine.
>WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
>same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
>_______________________________________________
>Geotools-devel mailing list
>Geo...@li...
>https://lists.sourceforge.net/lists/listinfo/geotools-devel
>  
>