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=value1¶m2=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]
