i think i already proposed something like this long time ago But i think it was to avoid collisions in the url and more expressive urls?
but this rename is fine by me except the wicket:bookmarkablePage that can be shorted like w:bookmarkablePage because the urls really says that it is bookmarkable (and all old urls must still work so wicket:bookmarkablePage must keep working) better would it in my eyes if developers could customize this them self. So have a settings class where they can be configured We (servoy) already had this for a large part but this we do by completely subclassing/copying WebRequestCodingStrategy so these should change: /** Name of interface target query parameter */ public static final String NAME_SPACE = "wicket:"; /** Name of interface target query parameter */ public static final String INTERFACE_PARAMETER_NAME = NAME_SPACE + "interface"; /** AJAX query parameter name */ public static final String BEHAVIOR_ID_PARAMETER_NAME = NAME_SPACE + "behaviorId"; /** Parameter name used all over the place */ public static final String BOOKMARKABLE_PAGE_PARAMETER_NAME = NAME_SPACE + "bookmarkablePage"; /** Pagemap parameter constant */ public static final String PAGEMAP = NAME_SPACE + "pageMapName"; into something like public static final String NAME_SPACE = Application.get ().getSettings().getNameSpace(); But ofcourse directly that can't be done so i guess we need to push them from our init phase johan On 7/25/07, Al Maw <[EMAIL PROTECTED]> wrote:
Hi folks, Although some people don't really care what their URLs look like, lots of people do. If you use UrlCompressingWebCodingStrategy you can get the actual parameter values for interface/behaviour/etc. URLs looking pretty small and inoffensive. But the name is still something large, like "wicket:interface". I'm wondering if for 1.3 we could replace that with just: wicket:interface --> w:i wicket:behaviourId --> w:b wicket:bookmarkablePage --> w:p wicket:pageMapName --> w:m It'd make the URLs shorter and not really any less comprehensible (this stuff only really means anything to people who understand the internals anyway). It'd make things very marginally quicker (less string matching). In short, I can't really see any disadvantage to it, other than that it will break any existing bookmarks to non-mounted pages. I'm pretty sure that the upgrade from 1.2 to 1.3 breaks these anyway. It's a trivial fix (just update the constants in WebRequestCodingStrategy and a bunch of expected unit test results). What do people think? Regards, Al -- Alastair Maw Wicket-biased blog at http://herebebeasties.com
