Justin Deoliveira wrote: > Well the way I see it going is that the rest stuff will be rewritten > against the new configuration classes. I dont think it will be too much > to switch over... and we can still keep the rest of the code base > againast the old model... and things will still be in sync. > I like that plan - make only the new config model available via the REST API. It gets the new config model some time in front of developers and gives us a real motivation to switch the remaining modules over (ie so they can be seen by programmers that are using the REST API). >> So far we have an old Wicket prototype and a new Cocoon prototype. >> I tried some other technologies, such as Struts2 + freemarker, but >> rapidly got out of my "comfort zone", that is, they rapidly became >> too annoying to use for weekend projects. >> I suspect that the Cocoon prototype meets all of our requirements exception "fashion". Both cocoon and wicket provide a nice formal split between model and view; one using XSLT and the other using a fill in the blank template. Personally I have let whatever XSLT skills I had slide, I am not sure what the comfort zone is for others?
Jody ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
