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]
