[Wicket-user] Pethate - long urls
Hey all, so I'm starting to play with Wicket and loving it, but I currently have a small pethate with the URL scheme used in the application.I realize the look of the URL shouldn't really matter, but I keep finding myself disliking it. Currently my app shows a URL like: http://localhost:8081/quickstart/app?bookmarkablePage=com.theoryinpractice.testapp.pages.CommentsPage Is there a way to get the app to resolve the above using something like: http://localhost:8081/quickstart/app/page/Podcomments or even http://localhost:8081/quickstart/app?page=Podcomments I guess it could be possible to say 'register' the package com.theoryinpractice.testapp.pages as a place where pages could be found and resolve the class to use instead of using the FQN all the time, this would only work in the case of unambiguous classes thou. Or maybe theres something already in wicket for more REST like URL schemes? I notice in the basic framework there's only a BookmarkablePage extension of Page, is there something in wicket-stuff maybe?
Re: [Wicket-user] Pethate - long urls
Hi Mark, if you are using wicket1.1 then your only choice is pretty much to use a url rewriting filter to dress up the url. this is pretty easy to do. there is a good filter here: http://tuckey.org/urlrewrite/ you can also add an alias to your page so it uses that in the url instead of fqn. but this is no longer supported in 1.2 if you are using wicket1.2 you have a lot more flexibility when it comes to urls. we provide a mounting mechanism that allows you to mount a bookmarkable page along with its parameters on a url of your choice. For example if you have a bookmarkable page B that takes pageparameters contaning P1=V1 and P2=V2 and you mount it on path /page it will be accissible through server/context/app/page/P1/V1/P2/V2 you can control how the parameter encoding happens by providing your own implementation of IPageParametersEncoder if the above (default so far) doesnt work for you. for examples on how to set the above up please see the cvs HEAD of wicket-examples - niceurls. -Igor On 12/3/05, Mark Derricutt [EMAIL PROTECTED] wrote: Hey all, so I'm starting to play with Wicket and loving it, but I currently have a small pethate with the URL scheme used in the application.I realize the look of the URL shouldn't really matter, but I keep finding myself disliking it. Currently my app shows a URL like: http://localhost:8081/quickstart/app?bookmarkablePage=com.theoryinpractice.testapp.pages.CommentsPage Is there a way to get the app to resolve the above using something like: http://localhost:8081/quickstart/app/page/Podcomments or even http://localhost:8081/quickstart/app?page=Podcomments I guess it could be possible to say 'register' the package com.theoryinpractice.testapp.pages as a place where pages could be found and resolve the class to use instead of using the FQN all the time, this would only work in the case of unambiguous classes thou. Or maybe theres something already in wicket for more REST like URL schemes? I notice in the basic framework there's only a BookmarkablePage extension of Page, is there something in wicket-stuff maybe?
Re: [Wicket-user] Pethate - long urls
Igor, cool - looks like that mounting option would suffice :) I just pulled out HEAD but see it uses Maven to build so I'm just gonna go install that.I assume any additional parameters passed via the traditional ?foo=barbar=foo scheme will be added to the PageParameters instance as well? MarkOn 12/3/05, Igor Vaynberg [EMAIL PROTECTED] wrote: set the above up please see the cvs HEAD of wicket-examples - niceurls.
Re: [Wicket-user] Pethate - long urls
Hi, answers below http://localhost:8081/quickstart/app?bookmarkablePage=com.theoryinpractice.testapp.pages.CommentsPage Is there a way to get the app to resolve the above using something like: http://localhost:8081/quickstart/app/page/Podcomments or even http://localhost:8081/quickstart/app?page=Podcomments Yep there is, but I just killed it in HEAD to do some rethinking. You could register aliases for classes which would then be used (so support for the second case). The rethinking is: - is this for pages only, or is it more general (answer is yes, because we want to use this for packaged resources too). - do we want the class/ alias mapping, or do we want to support other cases like the packages you suggest. - how are we going to name it But it'll be in there again shortly when we have answers to those questions... probably this week. I think in 1.1 it is called pageAlias in Application somewhere. One of the examples uses it. You first approach is supported in the HEAD version now. Or maybe theres something already in wicket for more REST like URL schemes? I notice in the basic framework there's only a BookmarkablePage extension of Page, is there something in wicket-stuff maybe? You mean REST like encode everything that has to do with state in your url? Well, yes and no. In head we provide the option of 'mounting' paths to bookmarkable pages (or actually in at a lower level, you could mount any request target you want). The example we are working on that shows this is wicket.examples.niceurl in the wicket-examples project, and it lets you use Wicket with URLs like http://localhost:8080/wicket-examples/niceurl/path/to/page2/param1/value1/param2/value2 where path/to/page2 is the mount, and param1 and param2 are the page parameters. Currently, I am also working on abstracting the session even more and trying to defer creating an actual httpsession object (the default store for Wicket WebApplications) until it is absolutely needed. The interesting thing here is that as long as you have a bookmarkable page with nothing on it that points back to that page, there shouldn't be a need to put it in the session. So, if I pull this off, it means that you can create completely stateless applications. Of course that won't help you with creating the kind of applications Wicket was targetted for in the first place, but it is a nice optimization and extra usuability I think. I you /do/ have call backs like forms etc, we need to store that page in the session - at least temporarily - in order to call the approariate methods on the target components. In that case, you application is not REST. And personally I don't agree with the REST thing for web applications anyway (and I'm in the web CBD/ Continuations camp for that matter), as the original concept of REST works fine for document centric view of the web (you know, the way it all started) and can even work for web apps that have a very direct 1-1 relationship with requests (i.e. they are relatively simple), but not for the kind of applications that people expect to work nowadays. And the guys from the web mvc camp... they are not exactly following the REST approach as it was intended either. Anway, big sidestep... I am getting almost emotional about defending against REST and stateless-ness as it seems to be a pavlov reaction for people to think that that is the only way to do your web applications :) Eelco --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37alloc_id865op=click ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Pethate - long urls
no, the additional parameters will not be added, in fact it will probably cause an exception. this is because the part of the url after the mount is processed by the page parameters encoder that is expecting format (/param-name/param-value)* its pretty easy to create an encoder that will process regular url formatted parameters. maybe that is a better default eventhough it is not as crawler friendly as the other one. you can also change your own implementation to the default by calling applicationsettings.setpageparametersencoder. hmm, having a parameters encoder that prepends the params with a .html can be interesting. then your mounted pages can look like /app/page.html?param=value kinda funny -Igor On 12/3/05, Mark Derricutt [EMAIL PROTECTED] wrote: Igor, cool - looks like that mounting option would suffice :) I just pulled out HEAD but see it uses Maven to build so I'm just gonna go install that.I assume any additional parameters passed via the traditional ?foo=barbar=foo scheme will be added to the PageParameters instance as well? MarkOn 12/3/05, Igor Vaynberg [EMAIL PROTECTED] wrote: set the above up please see the cvs HEAD of wicket-examples - niceurls.
Re: [Wicket-user] Pethate - long urls
oh and btw you can specify a page parameters encoder on per mount basis as well. -Igor On 12/3/05, Igor Vaynberg [EMAIL PROTECTED] wrote: no, the additional parameters will not be added, in fact it will probably cause an exception. this is because the part of the url after the mount is processed by the page parameters encoder that is expecting format (/param-name/param-value)* its pretty easy to create an encoder that will process regular url formatted parameters. maybe that is a better default eventhough it is not as crawler friendly as the other one. you can also change your own implementation to the default by calling applicationsettings.setpageparametersencoder. hmm, having a parameters encoder that prepends the params with a .html can be interesting. then your mounted pages can look like /app/page.html?param=value kinda funny -Igor On 12/3/05, Mark Derricutt [EMAIL PROTECTED] wrote: Igor, cool - looks like that mounting option would suffice :) I just pulled out HEAD but see it uses Maven to build so I'm just gonna go install that.I assume any additional parameters passed via the traditional ?foo=barbar=foo scheme will be added to the PageParameters instance as well? MarkOn 12/3/05, Igor Vaynberg [EMAIL PROTECTED] wrote: set the above up please see the cvs HEAD of wicket-examples - niceurls.
Re: [Wicket-user] Pethate - long urls
I was about to ask that actually :)On 12/3/05, Igor Vaynberg [EMAIL PROTECTED] wrote: oh and btw you can specify a page parameters encoder on per mount basis as well.
Re: [Wicket-user] Pethate - long urls
So pages with only bookmarkable links (and no other links) and no forms are not stored in the session?could be nice yes.Another thing i think of is having SingletonPage in the session. So that a bookmarkable link always goes to the same page if there is already one there in the page mape (stored with the mount url instead of path=x)Then every other kind of link or form can generate the mount url als there url where the do there get/post request to. Then the url stays the same even if you click on a link or submit a form.Of course users have to give is a hint that that page can be used that way (because this is not possible/wanted in all cases)with a marker interface or something. johanOn 12/3/05, Eelco Hillenius [EMAIL PROTECTED] wrote: Hi, answers below http://localhost:8081/quickstart/app?bookmarkablePage=com.theoryinpractice.testapp.pages.CommentsPage Is there a way to get the app to resolve the above using something like: http://localhost:8081/quickstart/app/page/Podcomments or even http://localhost:8081/quickstart/app?page=PodcommentsYep there is, but I just killed it in HEAD to do some rethinking. You could register aliases for classes which would then be used (sosupport for the second case).The rethinking is:- is this for pages only, or is it more general (answer is yes,because we want to use this for packaged resources too). - do we want the class/ alias mapping, or do we want to support othercases like the packages you suggest.- how are we going to name itBut it'll be in there again shortly when we have answers to those questions... probably this week. I think in 1.1 it is called pageAliasin Application somewhere. One of the examples uses it.You first approach is supported in the HEAD version now. Or maybe theres something already in wicket for more REST like URL schemes? I notice in the basic framework there's only a BookmarkablePage extension of Page, is there something in wicket-stuff maybe?You mean REST like encode everything that has to do with state in your url? Well, yes and no. In head we provide the option of 'mounting'paths to bookmarkable pages (or actually in at a lower level, youcould mount any request target you want). The example we are workingon that shows this is wicket.examples.niceurl in the wicket-examplesproject, and it lets you use Wicket with URLs likehttp://localhost:8080/wicket-examples/niceurl/path/to/page2/param1/value1/param2/value2 where path/to/page2 is the mount, and param1 and param2 are the page parameters.Currently, I am also working on abstracting the session even more andtrying to defer creating an actual httpsession object (the default store for Wicket WebApplications) until it is absolutely needed.The interesting thing here is that as long as you have a bookmarkablepage with nothing on it that points back to that page, there shouldn't be a need to put it in the session. So, if I pull this off, it meansthat you can create completely stateless applications. Of course thatwon't help you with creating the kind of applications Wicket wastargetted for in the first place, but it is a nice optimization and extra usuability I think.I you /do/ have call backs like forms etc, we need to store that pagein the session - at least temporarily - in order to call theapproariate methods on the target components. In that case, you application is not REST. And personally I don't agree with the RESTthing for web applications anyway (and I'm in the web CBD/Continuations camp for that matter), as the original concept of RESTworks fine for document centric view of the web (you know, the way it all started) and can even work for web apps that have a very direct1-1 relationship with requests (i.e. they are relatively simple), butnot for the kind of applications that people expect to work nowadays. And the guys from the web mvc camp... they are not exactly followingthe REST approach as it was intended either. Anway, big sidestep... Iam getting almost emotional about defending against REST andstateless-ness as it seems to be a pavlov reaction for people to think that that is the only way to do your web applications :)Eelco---This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems?Stop!Download the new AJAX search engine that makessearching your log files as easy as surfing theweb.DOWNLOAD SPLUNK!http://ads.osdn.com/?ad_idv37alloc_id865opclick ___Wicket-user mailing listWicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Pethate - long urls
I agree. I made the suggestion last month: http://sourceforge.net/mailarchive/message.php?msg_id=13756383I really like the architecture of Wicket although I have not used it much yet. The long url's is the one thing about Wicket that seemed would be a problem. It appears that the development team is considering some improvements with simplified url's.JeffMark Derricutt [EMAIL PROTECTED] wrote:Hey all, so I'm starting to play with Wicket and loving it, but I currently have a small pethate with the URL scheme used in the application.I realize the look of the URL "shouldn't" really matter, but I keep finding myself disliking it. Currently my app shows a URL like: http://localhost:8081/quickstart/app?bookmarkablePage=com.theoryinpractice.testapp.pages.CommentsPage Is there a way to get the app to resolve the above using something like: http://localhost:8081/quickstart/app/page/Podcomments or even http://localhost:8081/quickstart/app?page=Podcomments I guess it could be possible to say 'register' the package com.theoryinpractice.testapp.pages as a place where pages could be found and "resolve" the class to use instead of using the FQN all the time, this would only work in the case of unambiguous classes thou. Or maybe theres something already in wicket for more REST like URL schemes? I notice in the basic frame work there's only a BookmarkablePage extension of Page, is there something in wicket-stuff maybe? Jeff Miller[EMAIL PROTECTED] Yahoo! Shopping Find Great Deals on Gifts at Yahoo! Shopping
Re: [Wicket-user] Pethate - long urls
Not only considering... we build it in! :) There's a couple of things we are working on yet, which are stated in the TODO doc in the niceurl example package. By looking at the commit log (Juergen did some fresh commits), these issues are getting closer to being fixed too. Eelco On 12/3/05, Jeff Miller [EMAIL PROTECTED] wrote: I agree. I made the suggestion last month: http://sourceforge.net/mailarchive/message.php?msg_id=13756383 I really like the architecture of Wicket although I have not used it much yet. The long url's is the one thing about Wicket that seemed would be a problem. It appears that the development team is considering some improvements with simplified url's. Jeff Mark Derricutt [EMAIL PROTECTED] wrote: Hey all, so I'm starting to play with Wicket and loving it, but I currently have a small pethate with the URL scheme used in the application. I realize the look of the URL shouldn't really matter, but I keep finding myself disliking it. Currently my app shows a URL like: http://localhost:8081/quickstart/app?bookmarkablePage=com.theoryinpractice.testapp.pages.CommentsPage Is there a way to get the app to resolve the above using something like: http://localhost:8081/quickstart/app/page/Podcomments or even http://localhost:8081/quickstart/app?page=Podcomments I guess it could be possible to say 'register' the package com.theoryinpractice.testapp.pages as a place where pages could be found and resolve the class to use instead of using the FQN all the time, this would only work in the case of unambiguous classes thou. Or maybe theres something already in wicket for more REST like URL schemes? I notice in the basic frame work there's only a BookmarkablePage extension of Page, is there something in wicket-stuff maybe? Jeff Miller [EMAIL PROTECTED] Yahoo! Shopping Find Great Deals on Gifts at Yahoo! Shopping --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37alloc_id865op=click ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Pethate - long urls
I haven't taken a look at the latest code yet but I believe you simply renamed the parameters to fixed single-character names (which I find equally ugly). Is it possible for you to let us map parameter names to arbitrary names we want? For example, I would alias bookmarkablePage to page. Similar to aliasClass() you'd have aliasParameter() or something. Gili Eelco Hillenius wrote: Not only considering... we build it in! :) There's a couple of things we are working on yet, which are stated in the TODO doc in the niceurl example package. By looking at the commit log (Juergen did some fresh commits), these issues are getting closer to being fixed too. Eelco On 12/3/05, Jeff Miller [EMAIL PROTECTED] wrote: I agree. I made the suggestion last month: http://sourceforge.net/mailarchive/message.php?msg_id=13756383 I really like the architecture of Wicket although I have not used it much yet. The long url's is the one thing about Wicket that seemed would be a problem. It appears that the development team is considering some improvements with simplified url's. Jeff Mark Derricutt [EMAIL PROTECTED] wrote: Hey all, so I'm starting to play with Wicket and loving it, but I currently have a small pethate with the URL scheme used in the application. I realize the look of the URL shouldn't really matter, but I keep finding myself disliking it. Currently my app shows a URL like: http://localhost:8081/quickstart/app?bookmarkablePage=com.theoryinpractice.testapp.pages.CommentsPage Is there a way to get the app to resolve the above using something like: http://localhost:8081/quickstart/app/page/Podcomments or even http://localhost:8081/quickstart/app?page=Podcomments I guess it could be possible to say 'register' the package com.theoryinpractice.testapp.pages as a place where pages could be found and resolve the class to use instead of using the FQN all the time, this would only work in the case of unambiguous classes thou. Or maybe theres something already in wicket for more REST like URL schemes? I notice in the basic frame work there's only a BookmarkablePage extension of Page, is there something in wicket-stuff maybe? Jeff Miller [EMAIL PROTECTED] Yahoo! Shopping Find Great Deals on Gifts at Yahoo! Shopping --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37alloc_id865op=click ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user -- http://www.desktopbeautifier.com/ --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Pethate - long urls
I haven't taken a look at the latest code yet Well, please do that first before commenting :) Eelco --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37alloc_id865op=click ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Pethate - long urls
Perhaps next time you can be bothered to look at the code before saying that we did something ugly.-IgorOn 12/3/05, Gili [EMAIL PROTECTED] wrote:I haven't taken a look at the latest code yet but I believe you simply renamed the parameters to fixed single-character names (which I findequally ugly). Is it possible for you to let us map parameter names toarbitrary names we want? For example, I would alias bookmarkablePage to page. Similar to aliasClass() you'd have aliasParameter() or something.GiliEelco Hillenius wrote: Not only considering... we build it in! :) There's a couple of things we are working on yet, which are stated in the TODO doc in the niceurl example package. By looking at the commit log (Juergen did some fresh commits), these issues are getting closer to being fixed too. Eelco On 12/3/05, Jeff Miller [EMAIL PROTECTED] wrote:I agree.I made the suggestion last month: http://sourceforge.net/mailarchive/message.php?msg_id=13756383 I really like the architecture of Wicket although I have not used it muchyet.The long url's is the one thing about Wicket that seemed would be a problem.It appears that the development team is considering someimprovements with simplified url's. JeffMark Derricutt [EMAIL PROTECTED] wrote:Hey all, so I'm starting to play with Wicket and loving it, but I currentlyhave a small pethate with the URL scheme used in the application.I realize the look of the URL shouldn't really matter, but I keep finding myself disliking it.Currently my app shows a URL like: http://localhost:8081/quickstart/app?bookmarkablePage=com.theoryinpractice.testapp.pages.CommentsPageIs there a way to get the app to resolve the above using something like: http://localhost:8081/quickstart/app/page/Podcomments or even http://localhost:8081/quickstart/app?page=PodcommentsI guess it could be possible to say 'register' the packagecom.theoryinpractice.testapp.pages as a place where pages could be found and resolve the class to use instead of using the FQN allthe time, this would only work in the case of unambiguous classes thou.Or maybe theres something already in wicket for more REST like URL schemes? I notice in the basic frame work there's only a BookmarkablePage extensionof Page, is there something in wicket-stuff maybe?Jeff Miller [EMAIL PROTECTED] Yahoo! Shopping Find Great Deals on Gifts at Yahoo! Shopping --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems?Stop!Download the new AJAX search engine that makes searching your log files as easy as surfing theweb.DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37alloc_id865op=click ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user --http://www.desktopbeautifier.com/---This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems?Stop!Download the new AJAX search engine that makessearching your log files as easy as surfing theweb.DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click___Wicket-user mailing listWicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Pethate - long urls
No problem. I was simply basing this on CVS diffs I saw on the mailing list, so I didn't pull this out of the air. I'll check it out now. Gili Eelco Hillenius wrote: I haven't taken a look at the latest code yet Well, please do that first before commenting :) Eelco --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37alloc_id865op=click ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user -- http://www.desktopbeautifier.com/ --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Pethate - long urls
There you go, this is the CVS diff I was commenting on.
bookmarkablePage is replaced with 5.
Original Message
Subject: [Wicket-autocvs] wicket/src/java/wicket/protocol/http
WebResponseWithCryptedUrl.java,1.7,1.8
WebRequestWithCryptedUrl.java,1.10,1.11
Date: Sun, 20 Nov 2005 14:20:33 +
From: Juergen Donnerstag [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Update of /cvsroot/wicket/wicket/src/java/wicket/protocol/http
In directory
sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv5227/src/java/wicket/protocol/http
Modified Files:
WebResponseWithCryptedUrl.java WebRequestWithCryptedUrl.java
Log Message:
fixed [ 1348681 ] Crypted URLs break onSelectionChanged handling
Index: WebRequestWithCryptedUrl.java
===
RCS file:
/cvsroot/wicket/wicket/src/java/wicket/protocol/http/WebRequestWithCryptedUrl.java,v
retrieving revision 1.10
retrieving revision 1.11
diff -C2 -d -r1.10 -r1.11
*** WebRequestWithCryptedUrl.java21 Oct 2005 15:21:59 -1.10
--- WebRequestWithCryptedUrl.java20 Nov 2005 14:20:31 -1.11
***
*** 35,39
/**
! * it extends WebRequest and decodes URLs encoded by
* WebResponseWithCryptedUrl. One reason for obfuscating the URL's
query string
* might be, that you don't want the details to be visible to the user to
--- 35,39
/**
! * It extends WebRequest and decodes URLs encoded by
* WebResponseWithCryptedUrl. One reason for obfuscating the URL's
query string
* might be, that you don't want the details to be visible to the user to
***
*** 46,53
/** URL querystring decoded */
private final String queryString;
!
/** URL query parameters decoded */
private final ValueMap parameters;
!
/**
* Constructor.
--- 46,53
/** URL querystring decoded */
private final String queryString;
!
/** URL query parameters decoded */
private final ValueMap parameters;
!
/**
* Constructor.
***
*** 66,76
// Get the crypt implementation from the application
ICrypt urlCrypt = Application.get().newCrypt();
// Decrypt the query string
final String queryString = urlCrypt.decrypt(secureParam);
!
// The querystring might have been shortened (length
reduced).
// In that case, lengthen the query string again.
this.queryString = rebuildUrl(queryString);
!
// extract parameter key/value pairs from the query string
this.parameters = analyzeQueryString(this.queryString);
--- 66,77
// Get the crypt implementation from the application
ICrypt urlCrypt = Application.get().newCrypt();
+
// Decrypt the query string
final String queryString = urlCrypt.decrypt(secureParam);
!
// The querystring might have been shortened (length
reduced).
// In that case, lengthen the query string again.
this.queryString = rebuildUrl(queryString);
!
// extract parameter key/value pairs from the query string
this.parameters = analyzeQueryString(this.queryString);
***
*** 85,101
this.parameters = new ValueMap();
}
!
// If available, add POST parameters as well. They are not
encrypted.
// The parameters from HttpRequest
final Enumeration paramNames = request.getParameterNames();
// For all parameters (POST + URL query string)
while (paramNames.hasMoreElements())
{
!String paramName = (String)paramNames.nextElement();
!
// Ignore the x parameter
if (!x.equalsIgnoreCase(paramName))
{
! String[] values = request.getParameterValues(paramName);
// add key/value to our parameter map
this.parameters.put(paramName, values);
--- 86,103
this.parameters = new ValueMap();
}
!
// If available, add POST parameters as well. They are not
encrypted.
// The parameters from HttpRequest
final Enumeration paramNames = request.getParameterNames();
+
// For all parameters (POST + URL query string)
while (paramNames.hasMoreElements())
{
! String paramName = (String)paramNames.nextElement();
!
// Ignore the x parameter
if (!x.equalsIgnoreCase(paramName))
{
! String[] values =
request.getParameterValues(paramName);
// add key/value to our parameter map
this.parameters.put(paramName, values);
***
*** 118,122
queryString = Strings.replaceAll(queryString, 3=,
interface=);
queryString = Strings.replaceAll(queryString, 5=,
Re: [Wicket-user] Pethate - long urls
this is for ENCRYPTED urls and has nothing to do with what we are discussing here.-IgorOn 12/3/05, Gili
[EMAIL PROTECTED] wrote: There you go, this is the CVS diff I was commenting on.
bookmarkablePage is replaced with 5. Original Message Subject: [Wicket-autocvs] wicket/src/java/wicket/protocol/httpWebResponseWithCryptedUrl.java,1.7,1.8WebRequestWithCryptedUrl.java
,1.10,1.11Date: Sun, 20 Nov 2005 14:20:33 +From: Juergen Donnerstag [EMAIL PROTECTED]To:
[EMAIL PROTECTED]Update of /cvsroot/wicket/wicket/src/java/wicket/protocol/httpIn directorysc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv5227/src/java/wicket/protocol/httpModified Files:
WebResponseWithCryptedUrl.java WebRequestWithCryptedUrl.javaLog Message:fixed [ 1348681 ] Crypted URLs break onSelectionChanged handlingIndex: WebRequestWithCryptedUrl.java===
RCS file:/cvsroot/wicket/wicket/src/java/wicket/protocol/http/WebRequestWithCryptedUrl.java,vretrieving revision 1.10retrieving revision 1.11diff -C2 -d -r1.10 -r1.11*** WebRequestWithCryptedUrl.java
21 Oct 2005 15:21:59 -1.10--- WebRequestWithCryptedUrl.java20 Nov 2005 14:20:31 -1.11** 35,39 /**!* it extends WebRequest and decodes URLs encoded by
* WebResponseWithCryptedUrl. One reason for obfuscating the URL'squery string* might be, that you don't want the details to be visible to the user to--- 35,39 /**!* It extends WebRequest and decodes URLs encoded by
* WebResponseWithCryptedUrl. One reason for obfuscating the URL'squery string* might be, that you don't want the details to be visible to the user to** 46,53 /** URL querystring decoded */
private final String queryString;! /** URL query parameters decoded */ private final ValueMap parameters;! /*** Constructor.--- 46,53 /** URL querystring decoded */
private final String queryString;! /** URL query parameters decoded */ private final ValueMap parameters;! /*** Constructor.** 66,76
// Get the crypt implementation from the application ICrypt urlCrypt = Application.get().newCrypt(); // Decrypt the query string final String queryString =
urlCrypt.decrypt(secureParam);! // The querystring might have been shortened (lengthreduced). // In that case, lengthen the query string again. this.queryString
= rebuildUrl(queryString);! // extract parameter key/value pairs from the query string this.parameters = analyzeQueryString(this.queryString);--- 66,77 // Get the crypt implementation from the application
ICrypt urlCrypt = Application.get().newCrypt();+ // Decrypt the query string final String queryString = urlCrypt.decrypt(secureParam);! // The querystring might have been shortened (length
reduced). // In that case, lengthen the query string again. this.queryString = rebuildUrl(queryString);! // extract parameter key/value pairs from the query string
this.parameters = analyzeQueryString(this.queryString);** 85,101 this.parameters = new ValueMap(); }! // If available, add POST parameters as well. They are not
encrypted. // The parameters from HttpRequest final Enumeration paramNames = request.getParameterNames(); // For all parameters (POST + URL query string) while (
paramNames.hasMoreElements()) {!String paramName = (String)paramNames.nextElement();! // Ignore the x parameter if (!x.equalsIgnoreCase(paramName))
{! String[] values = request.getParameterValues(paramName); // add key/value to our parameter map this.parameters.put(paramName, values);
--- 86,103 this.parameters = new ValueMap(); }! // If available, add POST parameters as well. They are notencrypted. // The parameters from HttpRequest
final Enumeration paramNames = request.getParameterNames();+ // For all parameters (POST + URL query string) while (paramNames.hasMoreElements()) {! String paramName = (String)paramNames.nextElement();
! // Ignore the x parameter if (!x.equalsIgnoreCase(paramName)) {! String[] values =request.getParameterValues(paramName);
// add key/value to our parameter map this.parameters.put(paramName, values);** 118,122 queryString = Strings.replaceAll(queryString, 3=,
interface=); queryString = Strings.replaceAll(queryString, 5=,bookmarkablePage=);! return queryString; }--- 120,124 queryString =
Strings.replaceAll(queryString, 3=,interface=); queryString = Strings.replaceAll(queryString, 5=,bookmarkablePage=);! return queryString;
}** 134,138 // Get a list of strings separated by the delimiter final StringList pairs = StringList.tokenize(queryString, );! // Go through each string in the list
for (IStringIterator iterator = pairs.iterator();iterator.hasNext();)--- 136,140 // Get a list of strings separated by the delimiter final StringList pairs = StringList.tokenize
(queryString, );! // Go through each string in the list for (IStringIterator iterator = pairs.iterator();iterator.hasNext();)** 178,185
Re: [Wicket-user] Pethate - long urls
Where should I be looking in the new codebase for the clean URL code
you were discussing? It's not where I was expecting it.
Gili
Igor Vaynberg wrote:
this is for ENCRYPTED urls and has nothing to do with what we are
discussing here.
-Igor
On 12/3/05, *Gili* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
There you go, this is the CVS diff I was commenting on.
bookmarkablePage is replaced with 5.
Original Message
Subject: [Wicket-autocvs] wicket/src/java/wicket/protocol/http
WebResponseWithCryptedUrl.java,1.7,1.8
WebRequestWithCryptedUrl.java ,1.10,1.11
Date: Sun, 20 Nov 2005 14:20:33 +
From: Juergen Donnerstag [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
To: [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
Update of /cvsroot/wicket/wicket/src/java/wicket/protocol/http
In directory
sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv5227/src/java/wicket/protocol/http
Modified Files:
WebResponseWithCryptedUrl.java WebRequestWithCryptedUrl.java
Log Message:
fixed [ 1348681 ] Crypted URLs break onSelectionChanged handling
Index: WebRequestWithCryptedUrl.java
===
RCS file:
/cvsroot/wicket/wicket/src/java/wicket/protocol/http/WebRequestWithCryptedUrl.java,v
retrieving revision 1.10
retrieving revision 1.11
diff -C2 -d -r1.10 -r1.11
*** WebRequestWithCryptedUrl.java 21 Oct 2005 15:21:59 -1.10
--- WebRequestWithCryptedUrl.java20 Nov 2005 14:20:31 -1.11
***
*** 35,39
/**
! * it extends WebRequest and decodes URLs encoded by
* WebResponseWithCryptedUrl. One reason for obfuscating the URL's
query string
* might be, that you don't want the details to be visible to the
user to
--- 35,39
/**
! * It extends WebRequest and decodes URLs encoded by
* WebResponseWithCryptedUrl. One reason for obfuscating the URL's
query string
* might be, that you don't want the details to be visible to the
user to
***
*** 46,53
/** URL querystring decoded */
private final String queryString;
!
/** URL query parameters decoded */
private final ValueMap parameters;
!
/**
* Constructor.
--- 46,53
/** URL querystring decoded */
private final String queryString;
!
/** URL query parameters decoded */
private final ValueMap parameters;
!
/**
* Constructor.
***
*** 66,76
// Get the crypt implementation from the application
ICrypt urlCrypt = Application.get().newCrypt();
// Decrypt the query string
final String queryString = urlCrypt.decrypt(secureParam);
!
// The querystring might have been shortened (length
reduced).
// In that case, lengthen the query string again.
this.queryString = rebuildUrl(queryString);
!
// extract parameter key/value pairs from the query
string
this.parameters = analyzeQueryString(this.queryString);
--- 66,77
// Get the crypt implementation from the application
ICrypt urlCrypt = Application.get().newCrypt();
+
// Decrypt the query string
final String queryString = urlCrypt.decrypt(secureParam);
!
// The querystring might have been shortened (length
reduced).
// In that case, lengthen the query string again.
this.queryString = rebuildUrl(queryString);
!
// extract parameter key/value pairs from the query
string
this.parameters = analyzeQueryString(this.queryString);
***
*** 85,101
this.parameters = new ValueMap();
}
!
// If available, add POST parameters as well. They are not
encrypted.
// The parameters from HttpRequest
final Enumeration paramNames = request.getParameterNames();
// For all parameters (POST + URL query string)
while ( paramNames.hasMoreElements())
{
!String paramName = (String)paramNames.nextElement();
!
// Ignore the x parameter
if (!x.equalsIgnoreCase(paramName))
{
! String[] values =
request.getParameterValues(paramName);
// add key/value to our parameter map
this.parameters.put(paramName, values);
--- 86,103
this.parameters = new ValueMap();
