I think that if the URL exposes the class hierarchy, then there's a bit more pressure to make that hierarchy well-named and sensible. Also, anything that makes page-exposing automatic is okay in my book. To this end I would support moving org.geoserver.w?s.web -> org.geoserver.web.w?s. I know I know, easy for me to say. :) I am not a Java person, but this seems like moving in the right direction.
Thanks, Mike Pumphrey OpenGeo - http://opengeo.org Andrea Aime wrote: > Hi, > I've been looking into ways to have Wicket automatically generate > nice looking mount points without having to manually register or > mount the urls. The thing did not go well, it is actually doable > but I found myself lost into some hairy code in the Wicket > WebRequestCodingStrategy class, which is not really meant for > easy subclassing, so I decided to stay away from it :) > In any case, if someone wants to try, have a look at > WebRequestCodingStrategy and the only subclass of it, > UrlCompressingWebCodingStrategy, which to be used actually > needs also the UrlCompressingWebRequestProcessor class. > > As an alternative I took David's patch and modified it > a bit so that: > - any page, not just menu pages, can be registered > and mounted with a nice path, by rolling PageInfo, > a MenuPaneInfo superclass that knows about mounting > - the nice path gets automatically computed, unless > manually overridden, from the class package and name > > The strategy makes it so that a page class like: > org.geoserver.web.data.layer.LayerPage > gets a path like: > data/layer/layer > and thus it's available at: > http://host:port/geoserver/web/data/layer/layer > > Basically the convention strips off org.geoserver.web > and Page and turns what remains in the path (thus the > double layer/layer, due to layer.LayerPage). > > For the current menu pages we don't have to move a finger, > but to get nice looking urls we should enforce some > better convention on class names, something like: > org.geoserver.web.data.layer.LayerListPage > org.geoserver.web.data.layer.NewLayerPage > org.geoserver.web.data.layer.EditLayerPage > which would turn into the following urls: > http://host:port/geoserver/web/data/layer/layerlist > http://host:port/geoserver/web/data/layer/newlayer > http://host:port/geoserver/web/data/layer/editlayer > > Also, in the web wms/wfs/wcs modules the root package > is like org.geoserver.w?s.web, to get good names we > should again uniform to the convention and use > org.geoserver.web.w?s instead. > > So it's a bit of work, but nothing so hard, and would > result in a better uniformity in the code as well. > > If we don't want to go down the convention path > PageInfo also allows to manually specify a mount path. > > Opinions? > > Cheers > Andrea > > > > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > Enter the BlackBerry Developer Challenge > This is your chance to win up to $100,000 in prizes! For a limited time, > vendors submitting new applications to BlackBerry App World(TM) will have > the opportunity to enter the BlackBerry Developer Challenge. See full prize > details at: http://p.sf.net/sfu/Challenge > > > ------------------------------------------------------------------------ > > _______________________________________________ > Geoserver-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geoserver-devel ------------------------------------------------------------------------------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
