Re: Param = null
tried https://lilo:8443/whisky/app/cat/id/1 ?
you might want to have a look at QueryStringUrlCodingStrategy
On 9/10/07, chickabee [EMAIL PROTECTED] wrote:
Here is the constructor of the class i have:
public CategoryBrowser(final PageParameters parameters) {
// Add the simplest type of label
add(new Label(message, Welcome to the Category Browser Page));
System.out.println(Param = + parameters.getString(id) );
}
When I use the url:
https://lilo:8443/whisky/app/cat/?id=1
Not to mention that i have been using the Nice Url here for the above class.
I get the following in consol output:
Param = null
Can anyone point out what may b wrong? I expected it to be:
Param = 1
--
View this message in context:
http://www.nabble.com/Param-%3D-null-tf4413478.html#a12589727
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
http://www.somatik.be
Microsoft gives you windows, Linux gives you the whole house.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Param = null
Simply Amazing! It works like a charm. So the Wicket syntx is: https://lilo:8443/whisky/app/cat/param1/value1/param2/value2 Gracias para la ayuda Fancis! = tried https://lilo:8443/whisky/app/cat/id/1 ? -- View this message in context: http://www.nabble.com/Param-%3D-null-tf4413478.html#a12589994 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Param = null
that is the default, you can changed it using a different UrlCodingStrategy On 9/10/07, chickabee [EMAIL PROTECTED] wrote: Simply Amazing! It works like a charm. So the Wicket syntx is: https://lilo:8443/whisky/app/cat/param1/value1/param2/value2 Gracias para la ayuda Fancis! = tried https://lilo:8443/whisky/app/cat/id/1 ? -- View this message in context: http://www.nabble.com/Param-%3D-null-tf4413478.html#a12589994 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://www.somatik.be Microsoft gives you windows, Linux gives you the whole house. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Param = null
Thanks again, and what will be the best way to make these url temper proof? Currently, if i break the key value pairs, the wicket app is very unhappy like below: Unexpected RuntimeException Root cause: java.lang.IllegalStateException: URL fragment has unmatched key/value pair: name/foo/id at org.apache.wicket.request.target.coding.AbstractRequestTargetUrlCodingStrategy.decodeParameters(AbstractRequestTargetUrlCodingStrategy.java:175) at org.apache.wicket.request.target.coding.BookmarkablePageRequestTargetUrlCodingStrategy.decode(BookmarkablePageRequestTargetUrlCodingStrategy.java:76) at org.apache.wicket.protocol.http.request.WebRequestCodingStrategy.targetForRequest(WebRequestCodingStrategy.java:384) at org.apache.wicket.protocol.http.WebRequestCycleProcessor.resolve(WebRequestCycleProcessor.java:175) Francis De Brabandere-2 wrote: that is the default, you can changed it using a different UrlCodingStrategy On 9/10/07, chickabee [EMAIL PROTECTED] wrote: Simply Amazing! It works like a charm. So the Wicket syntx is: https://lilo:8443/whisky/app/cat/param1/value1/param2/value2 Gracias para la ayuda Fancis! = tried https://lilo:8443/whisky/app/cat/id/1 ? -- View this message in context: http://www.nabble.com/Param-%3D-null-tf4413478.html#a12589994 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://www.somatik.be Microsoft gives you windows, Linux gives you the whole house. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Param-%3D-null-tf4413478.html#a12590261 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Param = null
no it is not! - its just 1 way the wicket syntax may be - you should look at mount and the existing coding-strategys as well as (if youre on 1.3 already) on the new HybridUrlCodingStrategy you can have fllowing URL flavors out of box: /app/page/value1/value2 (IndexedURLCoding) /app/page:0 (hybrid) /app/page/param1/value1/param2/value2 /app/page?param1=value1param2=value2 (forgot the name of the latter, jsut browse the javadocs) Regards Korbinian PS: you also are free to give wicket a own CodingStrategy by extending any of these strategys chickabee schrieb: Simply Amazing! It works like a charm. So the Wicket syntx is: https://lilo:8443/whisky/app/cat/param1/value1/param2/value2 Gracias para la ayuda Fancis! = tried https://lilo:8443/whisky/app/cat/id/1 ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Param = null
On 9/10/07, chickabee [EMAIL PROTECTED] wrote: These strategies are pretty nice, but the question remains why the decoder() method pukes out when there is mismatch of key value pairs. Hacker will be very happy with the current state of implementation. only if you deploy your application in development mode. in deployment mode only the internal error page. see IApplicationSettings#setInternalErrorPage(Class) gerolf = Korbinian Bachl wrote: no it is not! - its just 1 way the wicket syntax may be - you should look at mount and the existing coding-strategys as well as (if youre on 1.3 already) on the new HybridUrlCodingStrategy you can have fllowing URL flavors out of box: /app/page/value1/value2 (IndexedURLCoding) /app/page:0 (hybrid) /app/page/param1/value1/param2/value2 /app/page?param1=value1param2=value2 (forgot the name of the latter, jsut browse the javadocs) Regards Korbinian PS: you also are free to give wicket a own CodingStrategy by extending any of these strategys chickabee schrieb: Simply Amazing! It works like a charm. So the Wicket syntx is: https://lilo:8443/whisky/app/cat/param1/value1/param2/value2 Gracias para la ayuda Fancis! = tried https://lilo:8443/whisky/app/cat/id/1 ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Param-%3D-null-tf4413478.html#a12590606 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Param = null
On Monday, September 10, 2007, 12:23:36 PM, chickabee [EMAIL PROTECTED] wrote: I still do not see why the wicket should treat it as an internal error if there are missing parameters? I guess wicket needs to follow the same paradigm as in the raw HttpRequest, let the user pull the parameters if they exist and take their own decision if they do not. It does not make any sense for the Wicket to declare the state of emergency if the parameters key value do not match. Normally, it does, as in most cases the link would have been generated by the web-app or another external web-app, so if it's missing/corrupt, something odd is going on. You, of course, have the option to supply your own strategy if you want to attempt to cater for users doing partial/incorrect edits of the URL, and having your strategy guess what they meant, but it's rather an isolated requirement, so I don't think it would belong in the core... If you're trying to /avoid/ users editing the URL, however, there are other coding strategies for that that encrypt decrypt the URLs... /Gwyn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Param = null
only if you deploy your application in development mode. in deployment mode only the internal error page. see IApplicationSettings#setInternalErrorPage(Class) gerolf Thanks for the good piece of info. I still do not see why the wicket should treat it as an internal error if there are missing parameters? I guess wicket needs to follow the same paradigm as in the raw HttpRequest, let the user pull the parameters if they exist and take their own decision if they do not. It does not make any sense for the Wicket to declare the state of emergency if the parameters key value do not match. -- View this message in context: http://www.nabble.com/Param-%3D-null-tf4413478.html#a12590866 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Param = null
Yes you are right. I guess the the name u were looking for is: org.apache.wicket.request.target.coding.MixedParamUrlCodingStrategy These strategies are pretty nice, but the question remains why the decoder() method pukes out when there is mismatch of key value pairs. Hacker will be very happy with the current state of implementation. = Korbinian Bachl wrote: no it is not! - its just 1 way the wicket syntax may be - you should look at mount and the existing coding-strategys as well as (if youre on 1.3 already) on the new HybridUrlCodingStrategy you can have fllowing URL flavors out of box: /app/page/value1/value2 (IndexedURLCoding) /app/page:0 (hybrid) /app/page/param1/value1/param2/value2 /app/page?param1=value1param2=value2 (forgot the name of the latter, jsut browse the javadocs) Regards Korbinian PS: you also are free to give wicket a own CodingStrategy by extending any of these strategys chickabee schrieb: Simply Amazing! It works like a charm. So the Wicket syntx is: https://lilo:8443/whisky/app/cat/param1/value1/param2/value2 Gracias para la ayuda Fancis! = tried https://lilo:8443/whisky/app/cat/id/1 ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Param-%3D-null-tf4413478.html#a12590606 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Param = null
I would disagree because this is the first problem any web developer would like to address, what happens if their urls are being tempered manually, it should not result into any kind of error by the web framework, rather this is the application validation issue and to be handled by the application developer and not Wicket. Here is the example of app generated url: http://www.cnn.com/2007/WORLD/europe/09/10/madeleine.mccann/index.html And here is the manually tempered url: http://www.cnn.com/2007/WORLD/europe/09/10/Foo And see how nicely this is being handled by the application. Applications are architected considering the worst case scenario and not the ideal world. Right? Perhaps, I need to write my own implementation of AbstractRequestTargetUrlCodingStrategy. = Gwyn wrote: On Monday, September 10, 2007, 12:23:36 PM, chickabee [EMAIL PROTECTED] wrote: I still do not see why the wicket should treat it as an internal error if there are missing parameters? I guess wicket needs to follow the same paradigm as in the raw HttpRequest, let the user pull the parameters if they exist and take their own decision if they do not. It does not make any sense for the Wicket to declare the state of emergency if the parameters key value do not match. Normally, it does, as in most cases the link would have been generated by the web-app or another external web-app, so if it's missing/corrupt, something odd is going on. You, of course, have the option to supply your own strategy if you want to attempt to cater for users doing partial/incorrect edits of the URL, and having your strategy guess what they meant, but it's rather an isolated requirement, so I don't think it would belong in the core... If you're trying to /avoid/ users editing the URL, however, there are other coding strategies for that that encrypt decrypt the URLs... /Gwyn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Param-%3D-null-tf4413478.html#a12591422 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Param = null
Pardon? All that's doing is showing their custom error page, exactly as the other replies have suggested that you'd want to do with Wicket - I'd be more impressed if it had shown an index of the news for that date, but as it is, that's just what you can easily do with Wicket. All you need to do is set your own custom error page and switch to Deployment mode, so as not to get the developer-friendly error messages. /Gwyn On Monday, September 10, 2007, 1:05:17 PM, chickabee [EMAIL PROTECTED] wrote: I would disagree because this is the first problem any web developer would like to address, what happens if their urls are being tempered manually, it should not result into any kind of error by the web framework, rather this is the application validation issue and to be handled by the application developer and not Wicket. Here is the example of app generated url: http://www.cnn.com/2007/WORLD/europe/09/10/madeleine.mccann/index.html And here is the manually tempered url: http://www.cnn.com/2007/WORLD/europe/09/10/Foo And see how nicely this is being handled by the application. Applications are architected considering the worst case scenario and not the ideal world. Right? Perhaps, I need to write my own implementation of AbstractRequestTargetUrlCodingStrategy. = Gwyn wrote: On Monday, September 10, 2007, 12:23:36 PM, chickabee [EMAIL PROTECTED] wrote: I still do not see why the wicket should treat it as an internal error if there are missing parameters? I guess wicket needs to follow the same paradigm as in the raw HttpRequest, let the user pull the parameters if they exist and take their own decision if they do not. It does not make any sense for the Wicket to declare the state of emergency if the parameters key value do not match. Normally, it does, as in most cases the link would have been generated by the web-app or another external web-app, so if it's missing/corrupt, something odd is going on. You, of course, have the option to supply your own strategy if you want to attempt to cater for users doing partial/incorrect edits of the URL, and having your strategy guess what they meant, but it's rather an isolated requirement, so I don't think it would belong in the core... If you're trying to /avoid/ users editing the URL, however, there are other coding strategies for that that encrypt decrypt the URLs... /Gwyn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] /Gwyn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Param = null
Ok, let me give you a different scenario and see if wicket has a way to handle it. Assume there are 10 parameters are being passed to the app as below: http://some.web.site/wicket/app/page/p1/v1/p2/v2/p3/v3/...p9/v9/p10/v10 Now If I mess-up the key value pair at the end like: http://some.web.site/wicket/app/page/p1/v1/p2/v2/p3/v3/...p9/v9/p10=v10 In that case how do i get the value of first 9 correct parameter and values? and do something with this available info, rather than blindly redirecting the user to the Error Page. Thanks.. === Gwyn wrote: Pardon? All that's doing is showing their custom error page, exactly as the other replies have suggested that you'd want to do with Wicket - I'd be more impressed if it had shown an index of the news for that date, but as it is, that's just what you can easily do with Wicket. All you need to do is set your own custom error page and switch to Deployment mode, so as not to get the developer-friendly error messages. /Gwyn On Monday, September 10, 2007, 1:05:17 PM, chickabee [EMAIL PROTECTED] wrote: I would disagree because this is the first problem any web developer would like to address, what happens if their urls are being tempered manually, it should not result into any kind of error by the web framework, rather this is the application validation issue and to be handled by the application developer and not Wicket. Here is the example of app generated url: http://www.cnn.com/2007/WORLD/europe/09/10/madeleine.mccann/index.html And here is the manually tempered url: http://www.cnn.com/2007/WORLD/europe/09/10/Foo And see how nicely this is being handled by the application. Applications are architected considering the worst case scenario and not the ideal world. Right? Perhaps, I need to write my own implementation of AbstractRequestTargetUrlCodingStrategy. = Gwyn wrote: On Monday, September 10, 2007, 12:23:36 PM, chickabee [EMAIL PROTECTED] wrote: I still do not see why the wicket should treat it as an internal error if there are missing parameters? I guess wicket needs to follow the same paradigm as in the raw HttpRequest, let the user pull the parameters if they exist and take their own decision if they do not. It does not make any sense for the Wicket to declare the state of emergency if the parameters key value do not match. Normally, it does, as in most cases the link would have been generated by the web-app or another external web-app, so if it's missing/corrupt, something odd is going on. You, of course, have the option to supply your own strategy if you want to attempt to cater for users doing partial/incorrect edits of the URL, and having your strategy guess what they meant, but it's rather an isolated requirement, so I don't think it would belong in the core... If you're trying to /avoid/ users editing the URL, however, there are other coding strategies for that that encrypt decrypt the URLs... /Gwyn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] /Gwyn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Param-%3D-null-tf4413478.html#a12592145 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Param = null
You write your own coding strategy, using the existing ones as guidelines/templates - I've not got any example code as supporting free-format user-created URL's isn't a scenario that's been relevant in the applications I've done. Wicket provides a number of strategies, but the fundamental point is that it while it attempts to provide for the majority of users, it also provides a framework and examples to allow those with unique requirements to develop their own solutions. /Gwyn On Monday, September 10, 2007, 1:58:55 PM, chickabee [EMAIL PROTECTED] wrote: Ok, let me give you a different scenario and see if wicket has a way to handle it. Assume there are 10 parameters are being passed to the app as below: http://some.web.site/wicket/app/page/p1/v1/p2/v2/p3/v3/...p9/v9/p10/v10 Now If I mess-up the key value pair at the end like: http://some.web.site/wicket/app/page/p1/v1/p2/v2/p3/v3/...p9/v9/p10=v10 In that case how do i get the value of first 9 correct parameter and values? and do something with this available info, rather than blindly redirecting the user to the Error Page. Thanks.. === Gwyn wrote: Pardon? All that's doing is showing their custom error page, exactly as the other replies have suggested that you'd want to do with Wicket - I'd be more impressed if it had shown an index of the news for that date, but as it is, that's just what you can easily do with Wicket. All you need to do is set your own custom error page and switch to Deployment mode, so as not to get the developer-friendly error messages. /Gwyn On Monday, September 10, 2007, 1:05:17 PM, chickabee [EMAIL PROTECTED] wrote: I would disagree because this is the first problem any web developer would like to address, what happens if their urls are being tempered manually, it should not result into any kind of error by the web framework, rather this is the application validation issue and to be handled by the application developer and not Wicket. Here is the example of app generated url: http://www.cnn.com/2007/WORLD/europe/09/10/madeleine.mccann/index.html And here is the manually tempered url: http://www.cnn.com/2007/WORLD/europe/09/10/Foo And see how nicely this is being handled by the application. Applications are architected considering the worst case scenario and not the ideal world. Right? Perhaps, I need to write my own implementation of AbstractRequestTargetUrlCodingStrategy. = Gwyn wrote: On Monday, September 10, 2007, 12:23:36 PM, chickabee [EMAIL PROTECTED] wrote: I still do not see why the wicket should treat it as an internal error if there are missing parameters? I guess wicket needs to follow the same paradigm as in the raw HttpRequest, let the user pull the parameters if they exist and take their own decision if they do not. It does not make any sense for the Wicket to declare the state of emergency if the parameters key value do not match. Normally, it does, as in most cases the link would have been generated by the web-app or another external web-app, so if it's missing/corrupt, something odd is going on. You, of course, have the option to supply your own strategy if you want to attempt to cater for users doing partial/incorrect edits of the URL, and having your strategy guess what they meant, but it's rather an isolated requirement, so I don't think it would belong in the core... If you're trying to /avoid/ users editing the URL, however, there are other coding strategies for that that encrypt decrypt the URLs... /Gwyn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Param = null
Thanks Gwyn for all the clarifications and patience, I believe I have all the answers now. Also, what's your take on adding an iterator to PageParameters that will help in looping over the parameters, rather than pulling them one at at time the way it is right now. I'm not sure if the same can be achieved some other way using the existing API. Any Ideas? === Gwyn wrote: You write your own coding strategy, using the existing ones as guidelines/templates - I've not got any example code as supporting free-format user-created URL's isn't a scenario that's been relevant in the applications I've done. Wicket provides a number of strategies, but the fundamental point is that it while it attempts to provide for the majority of users, it also provides a framework and examples to allow those with unique requirements to develop their own solutions. /Gwyn On Monday, September 10, 2007, 1:58:55 PM, chickabee [EMAIL PROTECTED] wrote: Ok, let me give you a different scenario and see if wicket has a way to handle it. Assume there are 10 parameters are being passed to the app as below: http://some.web.site/wicket/app/page/p1/v1/p2/v2/p3/v3/...p9/v9/p10/v10 Now If I mess-up the key value pair at the end like: http://some.web.site/wicket/app/page/p1/v1/p2/v2/p3/v3/...p9/v9/p10=v10 In that case how do i get the value of first 9 correct parameter and values? and do something with this available info, rather than blindly redirecting the user to the Error Page. Thanks.. === Gwyn wrote: Pardon? All that's doing is showing their custom error page, exactly as the other replies have suggested that you'd want to do with Wicket - I'd be more impressed if it had shown an index of the news for that date, but as it is, that's just what you can easily do with Wicket. All you need to do is set your own custom error page and switch to Deployment mode, so as not to get the developer-friendly error messages. /Gwyn On Monday, September 10, 2007, 1:05:17 PM, chickabee [EMAIL PROTECTED] wrote: I would disagree because this is the first problem any web developer would like to address, what happens if their urls are being tempered manually, it should not result into any kind of error by the web framework, rather this is the application validation issue and to be handled by the application developer and not Wicket. Here is the example of app generated url: http://www.cnn.com/2007/WORLD/europe/09/10/madeleine.mccann/index.html And here is the manually tempered url: http://www.cnn.com/2007/WORLD/europe/09/10/Foo And see how nicely this is being handled by the application. Applications are architected considering the worst case scenario and not the ideal world. Right? Perhaps, I need to write my own implementation of AbstractRequestTargetUrlCodingStrategy. = Gwyn wrote: On Monday, September 10, 2007, 12:23:36 PM, chickabee [EMAIL PROTECTED] wrote: I still do not see why the wicket should treat it as an internal error if there are missing parameters? I guess wicket needs to follow the same paradigm as in the raw HttpRequest, let the user pull the parameters if they exist and take their own decision if they do not. It does not make any sense for the Wicket to declare the state of emergency if the parameters key value do not match. Normally, it does, as in most cases the link would have been generated by the web-app or another external web-app, so if it's missing/corrupt, something odd is going on. You, of course, have the option to supply your own strategy if you want to attempt to cater for users doing partial/incorrect edits of the URL, and having your strategy guess what they meant, but it's rather an isolated requirement, so I don't think it would belong in the core... If you're trying to /avoid/ users editing the URL, however, there are other coding strategies for that that encrypt decrypt the URLs... /Gwyn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Param-%3D-null-tf4413478.html#a12592819 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
