Had a bit of a disappointment this week, while working (from my hotel room) on Tapestry.
I've been blissfully unaware of some limitations of the URL mappings for servlets in the web.xml file. Tapestry has always had a single, simple mapping, typically to
/app and everything else went into query parameters. That's changing for 3.1 and now I'm seeing some limitations in what I can do.
I'd like to support some mappings, such as
/Home.direct/border.link. That is, the direct service, the Home page, and the component border.link.
Alas, this can't be done. The web.xml mapping
<url-pattern>*.direct</url-pattern> will not match the above path. You'd think it would (and set the path info to
/border.link) but it simply doesn't match at all.
Give how rich Apache mod_rewrite is (despite the limitation of being written in C), you'd think there would be more flexibility for matching paths to servlets in the Servlet API. I haven't read the 2.4 specs yet, do they address this? Regardless, Tapestry has an explicit goal to stay compatible with Servlet API 2.2. I suspect this can be overcome as well with container specific extensions, but that's another thing to avoid since it always leaves some people out in the cold.
One possibility is that I'll support pattern of
/direct and create a URL like
/direct/Home/border.link, but given that the page name may itself have slashes (i.e.,
admin/AdminMenu or some such), this introduces unwanted ambiguities.
/Home and use a URL of
/Home/direct/border.link ... but suddenly, we start having a mapping for each page in the application!
In fact, I wish there was some delegate functionality in the servlet API, where application code could take over the identification of servlets for incoming paths. This would allow much richer paths. Alternately, it would be nice if the information provided in web.xml could be augmented, from
Servlet.init(ServletContext) with additional information provided by the application. This would allow us to not repeat ourselves, by having Tapestry provide mappings based on the available EngineServiceEncoder mappings.
I have no taste for bureaucracy, but I may yet need to find a place on the Servlet API expert group.