« Happy Halloween! | Main | Flex and Grails Made... »
20071101 Thursday November 01, 2007

Draft Specification for automatically mapping URLs to Controllers and Views Ted Husted has been working on a draft specification for "Heuristic Request/Response Mappings", based on technologies used by Rails, Struts 2 and Stripes.

The central idea is that instead of creating explicit mappings, the framework applies a series of heuristic transformations to match a URI with a code component and a view component.

The first part of the draft is available here:

* http://code.google.com/p/web-alignment-group/wiki/WAG_RFC_001

Before doing any more work on the description, I'd be very interested on feedback as to whether I'm making any sense, or whether the draft has turned into opaque gibberish :)

If you're developing a web framework (in any language) and use conventions to auto-map URLs-to-controllers and controllers-to-views, it'd be great to hear your feedback on this draft. It'd be pretty cool if you could switch frameworks/languages and use the same conventions across the board. Posted in Java at Nov 01 2007, 03:03:49 PM MDT 7 Comments

Comments:

https://stapler.dev.java.net/ anyone? It can be seen in action in https://hudson.dev.java.net

Posted by Renaud Bruyeron on November 02, 2007 at 01:18 AM MDT #

Grails come to mind too! There's a default URL mapping in place, that people can further customize to their delight.

Posted by Guillaume Laforge on November 02, 2007 at 01:47 AM MDT #

The problem with such a specification is that how does it take advantage of individual language features? We have a Groovy DSL which has a default strategy for mapping URLs onto controllers in Grails, but its comletely customizable: http://grails.org/URL+mapping And thanks to the power of Groovy, extremely expressive

Posted by Graeme Rocher on November 02, 2007 at 03:11 AM MDT #

I do a similar thing with my (personal) framework (feather.fourspaces.com - note: not quite ready for prime time), but automapping always scares me a bit. There is always one more constraint to add, another type of mapping that would be nice, or even another url scheme that should map to the same handler (method).

So, while I have default mappings of /controllerSimpleClassName/methodName, for me this actually ends up creating a set of Regular Expressions under the hood. Then for more fine grained mapping, you can apply annotations like @HttpPost, @Path("^/contact/(\d+)/view/$"), etc...

Ultimately, my feel for it is that the simple auto-mappings are great, until you need a little more flexibility... then it doesn't matter what the heuristic is, you'll still need to use whatever tools the framework gives you, be that annotations, xml config file, whatever. And at that point, you loose all of the cross-framework goodness, and you're back where you started.

Also regarding the RFC:

  1. I wonder how applicable this really could be to multiple languages...
  2. The entire thing seems to be based upon the matching of a requested URL to a handler/view... well, at least in my case, all of that is actually pre-calculated to create a list of matching regex's and their associated handlers. Is the Heuristic mapping implementation supposed to Ad hoc search for all of the handler possibilities each time? Would it be cached after the first hit?

Posted by Marcus Breese on November 02, 2007 at 02:36 PM MDT #

Great comments! These are exactly the sorts of questions that the site is trying to address. We have a lot of frameworks on a lot of platforms coming up with a lot of similar ideas. The key question is how can we document what Feather, Stapler, or Grails, or Groovy is doing in a way that other platforms can implement the same strategy?

-Ted.

Posted by Ted Husted on November 03, 2007 at 02:24 AM MDT #

I suggest you to take a look at what Tapestry 5 does. Copied from Tapestry 5's documentation Classes do not have to go directly inside the package (pages, components, mixins, etc.). It is valid to create a sub-package to store some of the classes. The sub-package name becomes part of the page name or component type. Thus you might define a page component com.example.myapp.pages.admin.CreateUser and the logical page name (which often shows up inside URLs) will be admin/CreateUser. Tapestry performs some simple optimizations of the logical page name (or component type, or mixin type). It checks to see if the package name is either a prefix or a suffix of the unqualified class name (case insensitively, of course) and removes the prefix or suffix if so. The net result is that a class name such as com.example.myapp.pages.user.EditUser will have a page name of user/Edit (not user/EditUser). The goal here is to provide shorter, more natural URLs.

Posted by Thiago HP on November 05, 2007 at 06:00 AM MST #

Tomcat used to come with a servlet mapper that mapped /servlet/classname to any callable class... This was eventually disabled, as it's a terrifying security hole. Anything you want to give public access to, you should have to map declaratively (with XML, annotations, or whatever).

Posted by Mark Hughes on November 09, 2007 at 05:54 PM MST #

Post a Comment:
  • HTML Syntax: Allowed
Click me to subscribe
Matt Raible is a Web Architecture Consultant specializing in open source frameworks.
« May 2012
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
  
       
Today

Recent Entries

Tag Cloud

abbie appfuse denver flex grails gwt hibernate jack java jsf linkedin maven myfaces rails roller skiing softwaresummit spring springmvc struts2 tapestry travel vacation webframeworks wicket