RE: Path-mapped action and Struts 1.1 beta

[Craig R. McClanahan]

On Mon, 1 Jul 2002, Martin Cooper wrote:

> Date: Mon, 1 Jul 2002 16:51:38 -0700
> From: Martin Cooper <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: 'Struts Developers List' <[EMAIL PROTECTED]>,
>  "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
> Subject: RE: Path-mapped action and Struts 1.1 beta
>
>
>
> > -Original Message-
> > From: Ted Husted [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, July 01, 2002 3:46 PM
> > To: Struts Developers List
> > Subject: Re: Path-mapped action and Struts 1.1 beta
> >
> >
> > "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?
> >
> > Underlying problem with modules and prefix mapping:
> >
> > Controller is inserting module name before "module-relative"
> > path. This
> > happens for all URIs, not just actions. So with
> > prefix-mapping, we'd not
> > only have /do/module1/action but /do/module/page.jsp.
> >
> > Killer kludge of the week:
> >
> > Use unknown action feature to trim servlet prefix from page requests.
> > When controller can't find the "page.jsp" action, it forward to a
> > standard unknown action that removes the servlet-mapping
> > prefix ("/do"),
> > and forwards again, this time to /module/page.jsp.
>
> Well, this suggests an interesting alternative to using a prefix for the
> default sub-app, knowing that the fact that no such sub-app is defined will
> cause the request to be sent to the default sub-app anyway... ;-)
>

Note that servlet containers follow exactly this kind of rule -- if the
container cannot match your request URI against the context path of any
known web application, it gives the request to the default webapp (the one
with a zero-length context path).

> --
> Martin Cooper
>

Craig


> >
> > =:0) Just kidding =:0)
> >
> > -- Ted Husted, Husted dot Com, Fairport NY US
> > -- Java Web Development 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]>
>
>
>
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: Path-mapped action and Struts 1.1 beta

[Martin Cooper]

> -Original Message-
> From: Ted Husted [mailto:[EMAIL PROTECTED]]
> Sent: Monday, July 01, 2002 3:46 PM
> To: Struts Developers List
> Subject: Re: Path-mapped action and Struts 1.1 beta
> 
> 
> "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?
> 
> Underlying problem with modules and prefix mapping: 
> 
> Controller is inserting module name before "module-relative" 
> path. This
> happens for all URIs, not just actions. So with 
> prefix-mapping, we'd not
> only have /do/module1/action but /do/module/page.jsp. 
> 
> Killer kludge of the week: 
> 
> Use unknown action feature to trim servlet prefix from page requests.
> When controller can't find the "page.jsp" action, it forward to a
> standard unknown action that removes the servlet-mapping 
> prefix ("/do"),
> and forwards again, this time to /module/page.jsp.

Well, this suggests an interesting alternative to using a prefix for the
default sub-app, knowing that the fact that no such sub-app is defined will
cause the request to be sent to the default sub-app anyway... ;-)

--
Martin Cooper

> 
> =:0) Just kidding =:0)
> 
> -- Ted Husted, Husted dot Com, Fairport NY US
> -- Java Web Development 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]>



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Path-mapped action and Struts 1.1 beta

[Ted Husted]

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

Underlying problem with modules and prefix mapping: 

Controller is inserting module name before "module-relative" path. This
happens for all URIs, not just actions. So with prefix-mapping, we'd not
only have /do/module1/action but /do/module/page.jsp. 

Killer kludge of the week: 

Use unknown action feature to trim servlet prefix from page requests.
When controller can't find the "page.jsp" action, it forward to a
standard unknown action that removes the servlet-mapping prefix ("/do"),
and forwards again, this time to /module/page.jsp.

=:0) Just kidding =:0)

-- Ted Husted, Husted dot Com, Fairport NY US
-- Java Web Development with Struts
-- Tel: +1 585 737-3463
-- Web: http://husted.com/about/services

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Path-mapped action and Struts 1.1 beta

[Martin Cooper]

For the first problem, you should be able to avoid this by using the
Content-Disposition header when returning the file data. I've used this
successfully in the past. Something like this:

response.setHeader("Content-Disposition", "inline; filename=" +
filename);

should do the trick.

Don't know about the second issue. Can you elaborate on the problem a bit?
We use a proxy server here at work, but I've never had problems with query
strings.

--
Martin Cooper


> -Original Message-
> From: Ted Husted [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, June 13, 2002 2:31 AM
> To: Struts Developers List
> Subject: Re: Path-mapped action and Struts 1.1 beta
> 
> 
> "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]>
> 
> 


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Path-mapped action and Struts 1.1 beta

[Ted Husted]

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

It looks like we need to call both getServletPath and getPathInfo, and
then subtract the servlet-mapping. 

Here's what the HttpRequest is willing to tell us: 

  
action
/do/*
  

action: ** PATH INFO:
action: /find/Last
action: ** PATH TRANS:
action: D:\public\tomcat\webapps\artimus\find\Last
action: ** QUERY STRING:
action: null
action: ** REQUEST URI:
action: /artimus/do/find/Last
action: ** SERVLET PATH:
action: /do


  
action
*.do
  

 action: ** PATH INFO:
 action: null
 action: ** PATH TRANS:
 action: null
 action: ** QUERY STRING:
 action: null
 action: ** REQUEST URI:
 action: /artimus/find/Last.do
 action: ** SERVLET PATH:
 action: /find/Last.do


If you do this 

servletPath + pathInfo

you get 

/do/find/Last

and 

/find/Last.do

respectively. 

So then we just need to mask the prefix (/do/*) or suffix (*.do) to get 

/find/Last

in either case. 

I believe this will make 

/do/module1/action

and 

/module1/action.do 

equivalent under 1.1 as it is under 1.0.


If this sounds reasonable, I'll give it a try. 

In 1.0, there was also a place in html:form that assumed extension
mapping and so prevented using extensions under prefix mapping. If the
rest works out, I'd check on that too. 


-- 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:   
For additional commands, e-mail: 

Re: Path-mapped action and Struts 1.1 beta

[Ted Husted]

"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:   
For additional commands, e-mail: 

Re: Path-mapped action and Struts 1.1 beta

[Craig R. McClanahan]

On Tue, 11 Jun 2002, James Young wrote:

> Date: Tue, 11 Jun 2002 21:40:05 -0700 (PDT)
> From: James Young <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Path-mapped action and Struts 1.1 beta
>
>
> As mentioned by Craig in
> http://www.mail-archive.com/struts-dev@jakarta.apache.org/msg04354.html,
> sub-app won't work for path-mapped actions, but only
> for extension-mapped actions.
>
> Has this issue been resolved?
>

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?

> James
>

Craig


--
To unsubscribe, e-mail:   
For additional commands, e-mail: