Consolitate WFSXmlParser classes
--------------------------------
Key: GEOS-2316
URL: http://jira.codehaus.org/browse/GEOS-2316
Project: GeoServer
Issue Type: New Feature
Components: WFS
Affects Versions: 1.7.0-RC4
Reporter: Andrea Aime
Assignee: Justin Deoliveira
Fix For: 1.7.1
At the moment we have 6 clones of the same class around:
org.geoserver.wfs.xml.v1_0_0.WfsXmlReader
org.geoserver.wfs.xml.v1_1_0.WfsXmlReader
org.geoserver.wfsv.xml.v1_0_0.WfsXmlReader
org.geoserver.wfsv.xml.v1_0_0.WfsvXmlReader
org.geoserver.wfsv.xml.v1_1_0.WfsXmlReader
org.geoserver.wfsv.xml.v1_1_0.WfsvXmlReader
The differences in the two WFS ones are minor but not too intuitive, and it's not clear to me if they are so be design or by accident, lack of comment as to why things are done a certain way is not helping.
I would like to have just _one_ abstract class that takes in all the differences as parameters, and has a getNamespace(): NamespaceInfo method that two subclasses, one for wfs, one for wfsv, implement (either that, or have WFSConfiguration and WFSVConfiguration share a superclass, or any other arrangement that allows to call the getCatalog() method without being concerned with the specific configuration class).
Then we can register the readers in the Spring context at will, changing the namespace, element name, version and service id at will.
I could do most of the work myself, I just need to figure out how to merge the wfs 1.0 and wfs 1.1 readers in one without breaking them.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira