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]
