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]
