Justin Deoliveira ha scritto: > The first would be to abandon the current architecture of trying to > autogenerate the object model from xml schema and come up with a central > non generated set of objects. Basically going back the old way of doing > things and the way wms does it. > > The pros of such an approach that i can see is: > > * Flexibility. Often things from the xml schema don't translate across > very well, or we want to model something slightly different than the xml > schema does > > * Stability. The service operations always get implemented in terms of a > stable object model. > > * Simplicity. This approach is much simpler than the gtxml/emf setup > which to my own fault has been over architected in a lot of places. > > The cons: > > * Parsing/encoding work. One of the nice things about using EMF as the > object model is that we can use dynamic bindings to do most of the > parsing and encoding work, which can be a time consuming task. > > * Maintenance. There is still the burden of manually updating the > internal object model to support changes in the spec. And depending on > the changes could be a significant task since different versions of a > spec can sometimes conflict > > The second option would be to stick with xsd/emf and generate a new > model for the new spec. And to reuse the operations with different > object models we use emf reflection to access the object model, as to > not depend on any specific version of the model.
I prefer this option. Maybe starting from a pojo object model that has been generated once from the xml schemas (if I can dream, so that documentation in the schema translates into the beans javadocs), but that can be then hacked by hand into the desired shape. As for bindings, I believe the EMF advantage over javabean reflection is that it knows what's inside collections? However that could be addressed by a form of reflective binding that just needs to know the collection data type. Maybe a bindings generator could scan the object model and interactively ask which class is the type of each collection around, and then generate the bindings for those (whilst for the classes that do not have collection childs, the normal javabeans reflection based one would do). Actually I believe maintenance is a plus on the side of this approach. Not having to depend on Eclipse tooling and playing with generating the interfaces or changing the schemas or whatever else should make maintenance easier and lower the learning curve for people that want to play with GeoServer sources. The times I had to massage an EMF model I would have dreamed of being able to just change the classes (always found the model update process quite convoluted and hard to remember). Cheers Andrea -- Andrea Aime OpenGeo - http://opengeo.org Expert service straight from the developers. ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
