Hi Lance, yes using @ActivationRequestParam was deffinately much cleaner since I didn't need an onActivate nor did I need to return a Link in onSuccess. BTW, is returning a link in onSuccess the right way to build the URL?
A problem I found with @ActivationRequestParam is my inability to handle exceptions properly. If someone puts a bunch of garbage in the URL, it results in an exception. Perhaps I just don't know how to handle them with @ActivationRequestParam, but at least I know with onActivate, I can handle them. My pk's are in fact longs, so my table structure is pk type long, name type string. I'm passing the object into my select menu, then when a user selects an item from the select menu and submits the results, you'll notice in onSuccess I'm getting the objects name and then passing the string name into the URL rather than the pk. I'm doing it this way because I didn't want pk's in my URLs, I'd prefer readable URLs for SEO. So as you can see, it unfortunately adds a lot more complexity to the code. So the question is should I create some sort of encoder that encodes all spaces with either an underscore or dash then later decodes it back?, or should I do the work up front and store a column in the database that already has either an underscore or a dash in place of a space? Option two seems like the better solution IMHO eliminating the chance of damaging a name that may by default contain those chars. Thanks Lance. -- View this message in context: http://tapestry.1045711.n5.nabble.com/How-to-remove-query-parmeter-from-url-string-tp5716922p5716998.html Sent from the Tapestry - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
