Hi all, I spent this last week looking at the rest config module in preparation in moving it toward supported. First off I want to say I really like restlet, and in particular the framework David has set up in GeoServer. It is quite easy to use and understand. That said I do think there is room for improvement. Here are some of the higher level things i have come up with.
* Old Configuration / Catalog API All the code is written against the deprecated configuration api. A while back when I did an initial review I brought this up and the response was that this would be something we would look at when moving rest config to supported, but for the purposes of experimentation we would just write against the old api. Well that time has come. In my opinion the code should work against the new api. I don't think it makes a lot of sense to release the code when we know it will need a major overhaul shortly after. Now at first thought this would require a lot of work, however i have some other suggestions below that will save a lot of the work. * Reflection vs Maps Currently "resources" in rest config all extend from a generic class called MapResource. MapResource works by having subclasses transform an object (say a FeatureTypeInfo) into a map, and vice versa. While this approach is straight forward and simple I think a reflection based approach would result in a lot less code. Especially for the new catalog and configuration interfaces. We all ready have a bunch of reflection utility classes (used by the ows dispatcher and xml parsers). And Andrea even made them fast by introducing a cache. Anyways, I think having a MapResource around is definitely useful for some cases, but I think another base class called something like "ReflectiveResource" would also be useful. * Serialization and De-serialization via XML and JSON An even bigger win with the reflective approach would be the serialization/de-serialization as XML and JSON via xstream. We already has code that does this as part of saving the configuration as xml with xstream. The exact same code can also be used to serialize as json with one flag set. So that basically means we don't have to write any custom serialization or de-serialization code. It also has the nice side-effect that when we output a resource via rest, it matches how we save the resource to disk. * Freemarker Templates for HTML output Currently when a resource is serialized as html it uses a built-in template. I think it makes sense to make this customizable for users with our fancy template system. I don't think this will be too much work. Basically just configure the template configuration used by FreemarkerFormat to use the GeoServerTemplateLoader to find a template, and fall back on the built-in templates. Thats it for now :). -Justin -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. ------------------------------------------------------------------------------ Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
