Looked a bit into this as well, and I agree it is tricky. One thing i am not crazy about with the proposed solution is putting the logic directly into the ComponentInfo (PageInfo) class. This class is designed to be relatively dumb, just metadata about the page. I think it makes more sense to keep all the mounting logic separate so it will be easier to swap it out. Baking it directly into ComponentInfo I fear it is something we will be stuck with since it is so central.
As a middle ground i would say perhaps keep mountPath on PageInfo, but move all the logic for figuring out what a sensible default is into GeoServerApplication. In terms of url mappings what about the slightly less verbose: LayerListPage -> .../layer/list LayerNewPage -> .../layer/new LayerEditPage -> .../layer/edit Also, for the edit case, don't we have to encode some state in the url? The id of the object being edited? I took the opportunity to play around expanding on the patch and here is what I came up with: 1) Add PageInfo same as the patch 2) Add PageInfo instances to the app context for all pages, not just ones linked from the main menu 3) In GeoServerApplication.init() do the dance of stripping off the package name, and inspect the class name to figure if it is a "list", "edit" , or "new" case. And mount the page class appropriately. The "edit" case is a bit tricky because it has state which needs to be represented in the url. Something like: http://.../layer/edit?id=<layerid> or: http://.../layer/edit/<layerid> Now at the end of the day all the edit pages basically hold onto the id of the object they are editing (I think some hold onto the actual object but I think there is a jira open to fix this, and make the behavior the same). Those pages that hold onto the id usually do so with a LoadableDetachable model. There is WorkspaceDetachableModel, LayerDetachableModel, etc... All those loadable detachable models could extend a single base class, something like "CatalogDetachableModel", which would look something like: class CatalogDetachableModel implements LoadableDetachableModel { String id; protected CatalogDetachableModel(String id) { this.id = id; } String getID() { return id; } final Object load() { return loadFromId(id); } protected abstract Object loadFromId(String id); } Now, in step 3 above, when GeoServerApplication is mounting all the classes from PageInfo, and it detects the edit case it would mount a specific implementation of IRequestTargetUrlCodingStrategy which in its encode() method calls page.getModel(), checks it for being an instanceof CatalogDetachableModel, and gets the id from it. The decode() method does the opposite, takes the id from the request and created the page from it. Thoughts? The additional work will be to make all the LoadableDetachableModels for catalog and config objects uniform, along with the edit pages that use them, but i think that is a plus. -Justin 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 -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. ------------------------------------------------------------------------------ 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
