Ya'll I wanted to create an application that had a path for each account. A Web 2.0 application. Like Twitter, the account would be part of the path.
http://twitter.com/bigeasy For example. But there would still be some paths that were not accounts. http://twitter.com/help/why It turned out that you simply could not do... @UrlBinding(value = "/{account}/orders/edit/{order}") There is a place for a suffix on the final path element, but the UrlBinding implementation expects you to have a consistent path prefix. I ended up doing some URL rewriting that checked if the account existed and then forwarded the URL with the account remove from the URL and appended as a parameter to the query string. Eventually, this his a snag. I tried using UrlRewriteFilter, but decided that if I could use DynamicMappingFilter and have a more expressive pattern language, I'd keep it all in stripes. And so... @UrlPatternBinding(value = "/{account [A-Za-z0-9-]+ #isAccount}/ orders/[EMAIL PROTECTED] (edit|new)}/?{order}") The above says match an account against a regular expression. If it passes pass the result to the static isAccount method of the annotated class (which can query the database to see if the account exists in the database.) Match orders as a literal. There are one of two events edit or new. The order id is optional. So, you can lead with patterns, explicitly state which events can be called through the binding, explicitly state optional parameters. There is support for priorities as well. The matched bits are turned into parameters and added to the query parameters in a specially wrapped HttpServletRequest. Now, if you want to create a Wiki, you can even include match different paths. @UrlPatternBinding(value = "//{path .* #isValidPath}/[EMAIL PROTECTED] (new:post|edit:post)}") If it were the case that ":" was disallowed in any path, then the above Wiki pattern would provide a strategy to create or edit any path in a Wiki. The isValidPath method is a static method in the annotated class. There are three forms of static method that you can define. These first two formats are called for each part of a matched path. public static Object test(Matcher matcher); public static Object test(String string); This format will be called with the entire path once the path matches. public static Object test(String[] path); If the methods return an object, that object is used as the parameter value in the query parameters. If they return null, then they did not match. In implementing this solution, I've got some thoughts on how to make it easier to create new binding strategies, including the REST binding to verb strategy which I railed against like a frothing Jolt- Cola addled geek with terribly misaligned priorities. I'd like to add the ability to bind to other variables in the request. Specifically, the server, because I'd like to have a Basecamp hosting strategy for my app in the long run... http://account.domain.com/orders/edit/1 This is a very popular strategy and it's going to fit nicely into my grand plan. Which would mean that UrlBinding and ActionResolvers in general would have to bind to more than just a path, but an entire URL plus, for the REST folks, a verb. So why not bind against the full HTTP request? Or at least the combination of verb and full URL. -- Alan Gutierrez | [EMAIL PROTECTED] | http://blogometer.com/ | 504 717 1428 Think New Orleans | http://thinknola.com/ ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Stripes-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/stripes-users
