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
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.