Andrea Aime wrote: > 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). Something based on package structure could work. But we would have to make package naming and page naming *very* consistent... which I would love... but I am not sure what we have now fits the bill, there are still inconsistencies.
Instead what I was thinking was something along the following lines. Most of our pages fit the same paradigm. Considering a particular entity, lets say workspace for example, we have three pages: 1. a page that lists all workspaces, WorkspacePage 2. a page that shows/edits a particular workspace, WorkspaceEditPage 3. a page that creates a new workspace, WorkspaceNewPage Sometimes 2 and 3 are put into a single page. However, with that naming convention we could map: 1 -> "workspaces" 2 -> "workspaces/<wsid>" 3 -> "workspaces/new" So we could perhaps work with this convention to do some automagic mapping. I would need to look at the IRequestTargetUrlCodingStrategy class in more detail to take this any further, but that was my initial thought. > >> 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 > -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. ------------------------------------------------------------------------------ _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
