"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]>