Fair enough, I am not suggesting that we do, but I think for the future we should come up with a general convention of how to implement pages which basically follow the same paradigm: have a catalog/config object, need a form to change some of its properties, need to save that object after the fact.
Andrea Aime wrote: > Justin Deoliveira ha scritto: >> Hi all, >> >> Fixing I bug I started looking at DataAccessEditPage and notice that it >> relies a lot on MapModel to manage form/object interaction. This seems >> like a lot of unnecessary work: >> >> 1) all properties have to marshalled from object to map >> 2) each property needs it's own well known key >> 3) all properties then have to be unmarshalled from the map back to object >> >> Why not a CompoundPropertyModel? Or even using a regular PropertyModel >> would be more concise. >> >> If I am missing something obvious in the approach, I apologize. Just >> looking at that page it struck me as a different from the other pages I >> have seen. > > I was just surprised as you when I first seen the page. > Given the amount of work I did not care to recode the page to > follow the normal structure. > > Cheers > Andrea > -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. ------------------------------------------------------------------------------ The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
