>> >> 1. Always place services under a sub context path: >> >> This would involve creating "sub contexts" for everything (similar to >> what we do with the ows mapping today): >> >> /geoserver/ows -> OWS style services >> /geoserver/rest -> REST apis >> /geoserver/ui -> user interface > > Thi would make paths a bit longer, but I like the organisation yeah i dont mind the organization myself... the extra bit of path info is a bit of a pain... having something like /geoserver/rest/features/... might seem a bit strange. But i could go for it. > >> 2. Choose a UI framework that does not jsp >> >> This would cut down the ui list drastically. Although Wicket which is a >> top contender would still be in running. Perhaps this along with modular >> UI will make Wicket unbeatable. >> >> I also think that Spring's MVC stuff would allow us to work around this. > > If you just want to get rid of JPSs, you can add to the list Spring MVC > + fm templates, Struts2 + fm templates, GWT, JSF + facelets, Tapestry... > the list of jsp haters grows every day ;) Yeah...although I think any ui that goes back to the web server to load any resources, say html files... the same problem would occur.
-- Justin Deoliveira The Open Planning Project [EMAIL PROTECTED] ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
