Mailing-List: contact struts-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: struts-user@jakarta.apache.org
Message-ID: <3B8484EE.C6DFADB5@mclures.net>
Date: Wed, 22 Aug 2001 23:22:06 -0500
From: "david@mclures.net" <david@mclures.net>
MIME-Version: 1.0
To: struts-user@jakarta.apache.org, David.McLure@fmr.com
Subject: Re: struts-user Digest 22 Aug 2001 16:40:53 -0000 Issue 668
References: <998498453.69690.ezmlm@jakarta.apache.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Thanks for the idea Bill, this idea looks a little more elegant than my Struts hack idea since it wouldn't involve having to re-hack Struts each time it is re-released.  I'll want to mull it over some more but at first glance this looks pretty doable.

Also thanks to Tuesday's reply from Robert Parker.  I'm not sure we can achieve the results we need using the static web app mappings in the war file alone.  The reason is that we need to dynamically add a prefixing layer to our URIs to distinguish between the app root and the doc root.  The web.xml
mapping file would indeed allow us to map from "/bar" to "/foo/bar", but in our case we also need to dynamically map to other app root prefixes as well.

The main problem is that Struts [v1.0] seems to assume that the app root is always going to be a simple hardcoded slash "/" when in our case, if it is used at all, it is actually going to need to be dynamically generated as something resembling "/prefixspec/".  As such, we either need a way to
dynamically prefix to the app root, or we need to remove the app root prefix altogether and enforce the use of
relative URLs across all of our Struts based applications (which is also problematic).  Bill's idea would provide a slicker way of undoing what Struts does to the prefix layer of our URIs, but it would be nice if Struts would allow us to dynamically map the absolute path prefix somehow to begin with.

Thanks again,

David McLure

David.McLure@fmr.com
david@mclures.net

>
> Date: Wed, 22 Aug 2001 10:01:47 -0400
> To: struts-user@jakarta.apache.org
> From: Bill Clinton <bclinton@snipermail.com>
> Subject: Re: Relative URL problem in action taglib processing
> Message-ID: <3B83BB4B.5010606@snipermail.com>
>
> David,
>       I am doing something similiar in an application I am working on.
> While I am not stripping the slash, I am modifying the path returned by
> an action mapping by adding parameters to it without modifying any
> Struts code.
>
> I recommend this solution (or something similar):  Write an extension of
> ActionForward called SlashlessActionForward.  Make the constructor of
> this object take an Action forward object like this:
>
>      public SlashlessActionForward(ActionForward forward) {
>
>          setName(forward.getName());
>          setPath(forward.getPath());
>          setRedirect(forward.getRedirect());
>
>      }
>
> now, override the getPath() method to return the path without the slash.
> (you would also need to overide setPath() to set a String property in
> your class)
>
> you can now use this in an ActionClass perform method like this:
>
> SlashlessActionForward forward =
>         new SlashlessActionForward(mapping.findForward("success"));
> return forward;
>
> Bill

> > ------------------------------

>
> Date: Tue, 21 Aug 2001 15:21:05 +1000
> To: <struts-user@jakarta.apache.org>
> From: "Robert Parker" <robert_parker@racv.com.au>
> Subject: Re: Relative URL problem in action taglib processing
> Message-ID: <004a01c12a01$13b50990$69151f0a@racv.com.au>
>
> ----- Original Message -----
> From: <david@mclures.net>
> To: <struts-user@jakarta.apache.org>
> Sent: Tuesday, August 21, 2001 3:49 PM
> Subject: Relative URL problem in action taglib processing
>
> >
> > Preliminary testing would indicate that this hack does seem to work, but
> > I can't help but wonder: are we missing something?  Is there an easier,
> > more elegant way to achieve relative paths in action parameter
> > references?
> >
>
> I have been deploying my apps as webapps using a war file, that way, the
> paths are relative to the root directory of the deployed webapp.
>
> regards
>
> Rob