Justin Deoliveira ha scritto: > I like the idea of having nicer urls, but I this proposed solution seems > to get us only part of the way there. The given strategy gives us a nice > url for the top level pages, but what pages linked from those? As far as > I can tell the mount points don't seem to propagate down.
Nope, they do not, each page has to be mounted separately. Which would mean we have to register in the app context something that performs these registrations on a module per module basis. > I wonder if it makes sense to bridge this idea with some sort of custom > url encoding strategy, which seems to be the way to do this sort of > stuff in wicket. See IRequestTargetUrlCodingStrategy. > > Some quick googling leads me also to this: > > http://java.dzone.com/news/wicket-creating-restful-urls > > Which I think could fit in quite well with the current UI. I would like to see some sort of automatic mapping as well. Maybe something based on a package + class name convention. The code in the same ends up being: MixedParamUrlCodingStrategy productURLS = new MixedParamUrlCodingStrategy( "products", ProductDetailPage.class, new String[]{"id"} ); mount(productURLS); So in the end you have to mount the pages manually anyways it would seem, the strategy makes sure to provide a nice rest-y url. I think it would be nice if we had a mechanism so that when Wicket encounters a link as: http://host:port/geoserver/p1/p2/p3/name it automatically looks up for class: org.geoserver.web.p1.p2.p3.namePage without the need to mount it? No idea if it's possible at all, I'll dig a little. In any case, having nice rest-y URLs for entry points is nice. It is extra work, but worthwile. Mind, we'll end up with non rest-y URLs any time a non ajax action is performed or when we go back to an edited page, the usual hard to read link Wicket generates in that case is a path in a server side data structure allowing to retrieve back a specific page in a specific state (with certain contents and certain components visible and so on). > As for demo pages, yes, I think we should try to adapt this for any sort > of page. Probably MenuPageInfo and DemoLinkInfo should share a common > super type "PageInfo". Also DemoLinkInfo should be renamed to > DemoPageInfo for consistencies sake. So this PageInfo registration could be the information used to perform the mount-ing? Cheers Andrea -- Andrea Aime OpenGeo - http://opengeo.org Expert service straight from the developers. ------------------------------------------------------------------------------ _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
