[Geoserver-devel] Cleaning up Wicket web UI URLs

David_Winslow · June 29, 2009, 3:02pm

Hi all,

Some of us at OpenGeo have been lamenting the overly long/verbose URLs
produced by Wicket. Wicket provides a concept of 'mounting' pages at
particular URLs, which we could use to clean them up a bit. I've put
together a small patch (attached) that uses the title i18n key for menu
pages as the mounted path as a small example (note this is just a sort
of proof-of-concept, I am NOT proposing that we uses the title keys. I
am really NOT proposing that we i18n-ize the URLs.)

I'd like to add a 'prettyPath' or 'shortPath' field to MenuPageInfo to
allow those context items to provide a nice URL for the pages they
describe. We could leave it optional to avoid requiring a 'big-bang'
migration, but in the long run I'm not sure whether it should be
mandatory or not.

Another question I have is whether we should extend this support to
other types of contributed pages (demo links?)

Thoughts?

--
David Winslow
OpenGeo - http://opengeo.org/

(attachments)

mountPaths.patch (1.26 KB)

Michael_Melvin · June 29, 2009, 9:56pm

Very +1 on whatever it takes to getting nicer URLs into GeoServer.

I'll chime back in when we have the discussion on what exactly these pretty URLs should be.

Thanks,
Mike Pumphrey
OpenGeo - http://opengeo.org

David Winslow wrote:

Hi all,

Some of us at OpenGeo have been lamenting the overly long/verbose URLs
produced by Wicket. Wicket provides a concept of 'mounting' pages at
particular URLs, which we could use to clean them up a bit. I've put
together a small patch (attached) that uses the title i18n key for menu
pages as the mounted path as a small example (note this is just a sort
of proof-of-concept, I am NOT proposing that we uses the title keys. I
am really NOT proposing that we i18n-ize the URLs.)

I'd like to add a 'prettyPath' or 'shortPath' field to MenuPageInfo to
allow those context items to provide a nice URL for the pages they
describe. We could leave it optional to avoid requiring a 'big-bang'
migration, but in the long run I'm not sure whether it should be
mandatory or not.

Another question I have is whether we should extend this support to
other types of contributed pages (demo links?)

Thoughts?

--
David Winslow
OpenGeo - http://opengeo.org/

------------------------------------------------------------------------

------------------------------------------------------------------------------

------------------------------------------------------------------------

_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Cliff_Patterson1 · June 29, 2009, 10:02pm

Also strongly +1 on coming up with more sane URLs than the default ones Wicket generates. Good URLs can provide vital context clues to users about where they are in an application, and how the various pieces fit together.

Chris

On Jun 29, 2009, at 4:56 PM, Mike Pumphrey wrote:

Very +1 on whatever it takes to getting nicer URLs into GeoServer.

I'll chime back in when we have the discussion on what exactly these pretty URLs should be.

Thanks,
Mike Pumphrey
OpenGeo - http://opengeo.org

David Winslow wrote:

Hi all,

Some of us at OpenGeo have been lamenting the overly long/verbose URLs
produced by Wicket. Wicket provides a concept of 'mounting' pages at
particular URLs, which we could use to clean them up a bit. I've put
together a small patch (attached) that uses the title i18n key for menu
pages as the mounted path as a small example (note this is just a sort
of proof-of-concept, I am NOT proposing that we uses the title keys. I
am really NOT proposing that we i18n-ize the URLs.)

I'd like to add a 'prettyPath' or 'shortPath' field to MenuPageInfo to
allow those context items to provide a nice URL for the pages they
describe. We could leave it optional to avoid requiring a 'big-bang'
migration, but in the long run I'm not sure whether it should be
mandatory or not.

Another question I have is whether we should extend this support to
other types of contributed pages (demo links?)

Thoughts?

--
David Winslow
OpenGeo - http://opengeo.org/

------------------------------------------------------------------------

------------------------------------------------------------------------------

------------------------------------------------------------------------

_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

------------------------------------------------------------------------------
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Rob_Atkinson1 · June 29, 2009, 11:40pm

+1

but I'd also caution that we need to understand the workflow and
objects before committing. Justin and I had quite a long and
productive conversation in Perth about possible workflows - and how
these could be optimised for different roles (the service manager as
opposed to the data specialist or the presentation guru for example).

It would be really nice if the config was compilable into useful
documentation about what lives at what URL automatically, otherwise
this is an extra doco overhead.

Rob

On Tue, Jun 30, 2009 at 8:02 AM, Christopher
Patterson<cpatterson@anonymised.com> wrote:

Also strongly +1 on coming up with more sane URLs than the default
ones Wicket generates. Good URLs can provide vital context clues to
users about where they are in an application, and how the various
pieces fit together.

Chris

On Jun 29, 2009, at 4:56 PM, Mike Pumphrey wrote:

Very +1 on whatever it takes to getting nicer URLs into GeoServer.

I'll chime back in when we have the discussion on what exactly these
pretty URLs should be.

Thanks,
Mike Pumphrey
OpenGeo - http://opengeo.org

David Winslow wrote:

Hi all,

Some of us at OpenGeo have been lamenting the overly long/verbose
URLs
produced by Wicket. Wicket provides a concept of 'mounting' pages at
particular URLs, which we could use to clean them up a bit. I've put
together a small patch (attached) that uses the title i18n key for
menu
pages as the mounted path as a small example (note this is just a
sort
of proof-of-concept, I am NOT proposing that we uses the title
keys. I
am really NOT proposing that we i18n-ize the URLs.)

I'd like to add a 'prettyPath' or 'shortPath' field to MenuPageInfo
to
allow those context items to provide a nice URL for the pages they
describe. We could leave it optional to avoid requiring a 'big-bang'
migration, but in the long run I'm not sure whether it should be
mandatory or not.

Another question I have is whether we should extend this support to
other types of contributed pages (demo links?)

Thoughts?

--
David Winslow
OpenGeo - http://opengeo.org/

------------------------------------------------------------------------

------------------------------------------------------------------------------

------------------------------------------------------------------------

_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

------------------------------------------------------------------------------
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

------------------------------------------------------------------------------
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Justin_Deoliveira · June 30, 2009, 5:43am

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.

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.

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.

-Justin

David Winslow wrote:

Hi all,

Some of us at OpenGeo have been lamenting the overly long/verbose URLs
produced by Wicket. Wicket provides a concept of 'mounting' pages at
particular URLs, which we could use to clean them up a bit. I've put
together a small patch (attached) that uses the title i18n key for menu
pages as the mounted path as a small example (note this is just a sort
of proof-of-concept, I am NOT proposing that we uses the title keys. I
am really NOT proposing that we i18n-ize the URLs.)

I'd like to add a 'prettyPath' or 'shortPath' field to MenuPageInfo to
allow those context items to provide a nice URL for the pages they
describe. We could leave it optional to avoid requiring a 'big-bang'
migration, but in the long run I'm not sure whether it should be
mandatory or not.

Another question I have is whether we should extend this support to
other types of contributed pages (demo links?)

Thoughts?

--
David Winslow
OpenGeo - http://opengeo.org/

------------------------------------------------------------------------

------------------------------------------------------------------------------

------------------------------------------------------------------------

_______________________________________________
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.

Andrea_Aime3 · June 30, 2009, 6:53am

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.

Justin_Deoliveira · July 1, 2009, 7:00am

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.