Branched off existing config package as a starting point.
Updated the class descriptions, and marked the classes final (they are Data Transfer Objects after all).
Currently:
- WFSDTO - web feature server DTO holds a ServiceDTO and a base url
- WMSDTO - web map server DTO also holds a Service DTO
- ServiceDTO - serviec DTO holds fees, abstract, keywords and so on...
I am bit torn on allowing a common ServiceDTO class.While I understand code reuse I would like some one who knows the OGC specifications to confirm that the common elements actually *mean* the same thing to both the WMS/WFS services.
Can anyone help me out and confirm this?
One nice thing was placing the XML reading / writing code into global.xml. The class ends being dependent only on the DTO package, this speaks well for a nice clean design.
Nice work sorting out the configuration classes in the first place David.
Branched off existing config package as a starting point.
Updated the class descriptions, and marked the classes final (they are
Data Transfer Objects after all).
Currently:
- WFSDTO - web feature server DTO holds a ServiceDTO and a base url
- WMSDTO - web map server DTO also holds a Service DTO
- ServiceDTO - serviec DTO holds fees, abstract, keywords and so on...
I am bit torn on allowing a common ServiceDTO class.While I understand
code reuse I would like some one who knows the OGC specifications to
confirm that the common elements actually *mean* the same thing to both
the WMS/WFS services.
Can anyone help me out and confirm this?
I'm positive enough that they do mean the same thing to advise you to go
ahead and do it. I'm pretty sure the ogc plan is to unite the common
elements eventually - there's a Web Objects Specification that has base
elements adapted from the WFS spec. So the elements in WFS and WMS do
mean the same thing, the spec authors just didn't coordinate as well as
they could making sure that the semantics were exactly the same (like
LatLonBounding box vs. LatLongBoundingBox). But we should be fine to have
them represented teh same way.
One more thing to note - the base url that you specify in the WFSDTO
should actually be deprecated soon. It is possible, and not that
difficult, to figure out what url the request came from. The servlet api
has a few ways of figuring this out. If you guys have time I'd recommend
fixing that, as it's probably the single most annoying configuration item,
since getting it wrong means that clients won't process things correctly.
It could easily be done in 3-4 hours. It's in jira as GEOS-7.
TestWfsPost servlet shows one way to handle it. We just need to abstract
it up, probably have it as an element in Request, and have AbstractServlet
set it. If you guys don't do it I will get to it eventually, but this
month is looking really busy for me.