"Craig R. McClanahan" wrote: > No ... and (this time at least) not because of lack of time. It is not at > all obvious how to rig path mapping to the controller to work together > with the basic assumption of sub-applications that there is a prefix for > that subapp. All I can think of is requiring you to map the controller > once per subapp, which is both ugly and will require a bunch of changes to > the existing code that assumes there is only one mapping to the controller > servlet. > > Ideas, anyone?
Going at this from the other direction, there are two use-cases I've run into where extension-mapping is problematic. First, generating non-html files to be saved on the user's system. If you are returning something that is suppose to be a merge file or a spreadsheet, being able to process the request under the native extension helps the browser to do the right thing. Otherwise, for example, the browser may save a plain/text file designed for a mail-merge process wrapped in HTML. Being able to use URIs like /do/batch/ItemMercLabels.txt is very helpful to the user when they go to save a generated file for use with another software. Second, avoiding query strings on proxy servers. Some systems, like Amazon, use "extra path information" URIs like http://www.amazon.com/exec/obidos/ISBN=1861005512/bookstore Which would equate to something like http://www.amazon.com/do/obidos?ISBN=1861005512&bookstore or http://www.amazon.com/obidos.do?ISBN=1861005512&bookstore One nasty bit might be to use a helper servlet that used regular expressions (or something) to munch /do/batch/ItemMercLabels.txt /do/obidos/ISBN=1861005512/bookstore into /batch/ItemMercLabels.do /obidos.do?ISBN=1861005512&bookstore and forward the request internally through the container ... but that gives me the chills =:~| If we had cannonical solutions for these use-cases, I'd be out of reasons to suggest prefix mappings :0) -- Ted Husted, Husted dot Com, Fairport NY US -- Developing Java Web Applications with Struts -- Tel: +1 585 737-3463 -- Web: http://husted.com/about/services -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>