Proposal #1: Unifying encoders
Currently we have 2 different models, one to encode the xml to push to geoserver and one to read the xml incoming. This happened to make the encoder part much more flexible and lenient to the geoserver api changes.
Currently it is very hard to perform a read, modify and update of a configuration.
I'd like to unify the models simplifying the entire library structure:
-
using the XmlElement as encoder base class (which is essentially a Document) we can add generic calls to get/put/post still missing encoders so the library will be more agile and ready to use also for not well covered parts (geoserver global settings, and any new rest interface section on the geoserver side). Fe: If the list of coverages is still not covered by an encoder we can simply serialize it to an XmlElement like here An user can always parse it using utils provided here
-
The a new version of the calls found into the GeoServerRESTPublisher will be provided using the GeoServerRESTManager mechanism so the split of the front-end methods will start immediately. NOTE: the example provided here is only to show the changes to do. As explained in (2) The new calls may not change the current GeoServerRESTPublisher interface but deprecate them adding a new version extending the GeoServerRESTManager.
-
no other mapper / translate class should be provided to translate between models
-
all reader model classes can be removed (less code to maintain)
This will solve most of the typical usage problem such as:
- Make a request, modify it and push changes to the server currently we have to implement the reader + the mapper between reader and encoder + the encoder
- If an encoder is missing we can provide generic methods which can be used to retrieve an XmlElement (base class) which can be easily cast to a specialization.
The interface of the GeoServerRESTPublisher can still keep old methods deprecating it in favor of a new implementation of the GeoServerRESTManager returned by the GeoServerRESTManager. This can be performed on the new master branch which already introduced some not back-portable changes to that manager.
Any Others???