Justin Deoliveira ha scritto: > >>> >>> 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.
That's what happening today with the rest module extension point, so for example in the project I'm developing we have /geoserver/rest/csv/ /geoserver/rest/sldservice roots for the csv and sldservice REST services roots. >> >>> 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. We can do the same as with the file publisher and have the dispatcher serve stuff out of the classpath or redirect it to serve stuff from the web application dir (that is, do what the web server would have done). It's a must in a modular UI hypothesis, but if we don't go there, then it's probably a big ugly. Cheers Andrea ------------------------------------------------------------------------- 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
