Re: mountBookmarkablePage and missing parameters - exception thrown
I believe the org.apache.wicket.request.target.coding.AbstractRequestTargetUrlCodingStrategy.decodeParameters(), shold not throw a RunTime Exception as it does now, if the url is tampered, instead it should always provide the parameters and values to it's best guess and then let the user decided how the request needs to be processed. Also, org.apache.wicket.PageParameters, should provide one iterator with all available params, Any comments? igor.vaynberg wrote: On 8/8/07, Dariusz Wojtas [EMAIL PROTECTED] wrote: I want to use it in cases where the user may be given feeling that he is browsing some structure. well, my point was that structure is probably better represented by indexed coding strategy, which is forgiving. for example /products/clothes/tshirts/red (indexed) is better imho then /products/category/clothes/subcategory/tshirts/color/red (default) -igor -- View this message in context: http://www.nabble.com/mountBookmarkablePage-and-missing-parameters---exception-thrown-tf4219655.html#a12590494 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: mountBookmarkablePage and missing parameters - exception thrown
I believe this syntax should be forgiving to the user. A framework should ease life where possible. What is the benefit of encoding URLs /param1/value1/param2/value2 over ?param1=value1param2=value2 ? The way it is shown to the users. Not for developers. And not only for search engine spiders. I want to use it in cases where the user may be given feeling that he is browsing some structure. If we say 'a' and hide the implementation details from users - then why to prohibit saying 'b'? The only thing that should be checked (possibly already works) is to check if shorter path does not make incorrect assumptions on the nesting level when referring resources like CSS or IMG files. It matters if it generates '../../../style.css' or '../../style.css' But possibly this is already working. Darek Eelco Hillenius wrote: i dont see why we should support this. if you expect the user to mess with your urls then you should either leave it as a query string or use indexed coding strat. imho we should fail early - imagine looking at logs and trying to figure out wtf that url came from. could it be a wicket encoding problem? user messed with it? etc etc. I don't think it's always bad if people mess with parameters, especially not when it concerns paths like Dariusz mentioned. To me, it is natural to directly play with a path, though I wouldn't play with parameters if they come in the form ?foo=bar. I would prefer Wicket to be more forgiving and let users decide whether they have enough information to process a request. the code to support this wouldnt be hairy at all - just remove the check and see if param is missing and add it as ...hmm or maybe better to add it as null? see what i mean. Yeah, that's the kind of hairyness I meant. Then again, that could be just a setting. Eelco -- View this message in context: http://www.nabble.com/mountBookmarkablePage-and-missing-parameters---exception-thrown-tf4219655.html#a12061758 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: mountBookmarkablePage and missing parameters - exception thrown
On 8/8/07, Dariusz Wojtas [EMAIL PROTECTED] wrote: I want to use it in cases where the user may be given feeling that he is browsing some structure. well, my point was that structure is probably better represented by indexed coding strategy, which is forgiving. for example /products/clothes/tshirts/red (indexed) is better imho then /products/category/clothes/subcategory/tshirts/color/red (default) -igor
Re: mountBookmarkablePage and missing parameters - exception thrown
On 8/5/07, Igor Vaynberg [EMAIL PROTECTED] wrote: mount with indexed url coding strategy if you dont mind users messing with your urls. I think it's kind of annoying as well. Are we (Wicket devs) really against supporting this, or don't we support it because the code gets a bit hairy? Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
