Back to the original question... I found a solution and want to validate it:
1. I created a RequestFilter that maps to /*
2. This filter checks to see if request.getServletPath() matches any of the
action paths in struts-config.xml. If so, it forwards to the action.
3. As an added feature, I added a set of allowed extensions to this
filter's init parameters. So far I have .jsp,.html,.asp,.cfm (using .jsp
ensures no one links to them directly, MVC enforced!) - so marketing can
choose what technology they want to convey ;-)
This seems to work great. For example, I have an "advancedSearch" action
defined as follows:
<action path="/advancedSearch"
type="org.apache.struts.actions.ForwardAction"
parameter=".advancedSearch"/>
(ForwardAction will eventually be replaces, if necessary, with a real
action). This allows all of the following URLs to work:
http://site.com/do/advancedSearch (works with Struts by default)
http://site.com/advancedSearch
http://site.com/advancedSearch.html + all other extensions listed.
Pretty slick IMO. Please let me know if I'm missing anything.
Thanks,
Matt
Here's the code from RequestFilter.doFilter():
// get Struts' configuration
ModuleConfig m = getModuleConfig(request);
// get a list of actions
ActionConfig[] actions = m.findActionConfigs();
// get the requested path
String path = request.getServletPath();
for (int i = 0; i < actions.length; i++) {
ActionConfig action = actions[i];
String actionPath = action.getPath();
String params = RequestUtil.getRequestParameters(request);
// check to see if path ends with a vanity extension
for (int j = 0; j < allowedExtensions.length; j++) {
if (path.endsWith(allowedExtensions[j])) {
path =
path.substring(0, path.indexOf(allowedExtensions[j]));
break;
}
}
if (StringUtils.equalsIgnoreCase(actionPath, path)) {
StringBuffer url = new StringBuffer();
boolean redirect = false; // change to true if using redirect
if (redirect) {
url.append(request.getContextPath());
}
url.append("/do" + actionPath);
url.append((!StringUtils.isEmpty(params)) ? ("?" + params) : "");
if (log.isDebugEnabled()) {
log.debug("forwarding from path '" + path +
"' to action '" + actionPath + "'");
}
// This this until we have issues (this way the URL doesn't change)
RequestDispatcher dispatcher =
request.getRequestDispatcher(url.toString());
dispatcher.forward(request, response);
// If a forward doesn't work - use the one below
// Redirect the page to the desired URL
//
response.sendRedirect(response.encodeRedirectURL(url.toString()));
// ensure we don't chain to requested resource
return;
}
}
protected ModuleConfig getModuleConfig(HttpServletRequest request) {
ModuleConfig mConfig =
(ModuleConfig) request.getAttribute(Globals.MODULE_KEY);
if (mConfig == null) {
mConfig =
(ModuleConfig)
config.getServletContext().getAttribute(Globals.MODULE_KEY);
}
return mConfig;
}
-----Original Message-----
From: Jason Lea [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 18, 2003 3:10 PM
To: Struts Users Mailing List
Subject: Re: Is it possible to remove *.do or /do/* from the URL
If there are only a small number of 'marketing' style URLs that are
going to be used, you could do those mappings specifically in the
web.xml and leave everything else to your /do/* mapping
Eg Marketing URLs 'activities', 'contact', 'foo'
/activities/*
/contact/*
/foo/*
everything else
/do/*
Or you could wrap a filter around the /activities/*, /contact/*, /foo/*
mappings and forward to the correct action.
--
Jason Lea
Matt Raible wrote:
> The reason I don't like extension mapping is because I think path-mapping
> (/do/*) is cleaner. Also, I like using path-mapping b/c then we can add
> parameters and they look like regular URLs.
>
> For example - extension mapping:
>
> http://site.com/activities.do?activity=fishing or
> http://site.com/activities.do?fishing
>
> path-mapping:
>
> http://site.com/do/activities/fishing
>
> And then in our "activities" action, we can do a check
> (request.getPathInfo()) to see if we should serve up the "fishing" page
vs.
> the general activities one.
>
> Thanks to all for your opinions and practices.
>
> Matt
>
> -----Original Message-----
> From: Micael [mailto:[EMAIL PROTECTED]
> Sent: Thursday, September 18, 2003 11:33 AM
> To: Struts Users Mailing List; [EMAIL PROTECTED]
> Subject: Re: Is it possible to remove *.do or /do/* from the URL
>
>
> I use .Whatever, where that is some marketing term that is acceptable.
>
> At 10:39 AM 9/18/2003 -0400, Vic Cekvenich wrote:
>
>>How about a hack:
>>*.jsp
>>It looks as jsp on top.... but it's a do.
>>Or you can even say *.asp, or anything.
>>Just pick a word marketing likes.
>>
>>.V
>>
>>Matt Raible wrote:
>>
>>>I agree with you - however, it's a marketing thing. The project I'm on
>
> has
>
>>>implemented a lot of folder/index.html (with meta-refresh) so that
>
> marketing
>
>>>materials have pretty URLs. I was simply hoping to accomplish this
>
> without
>
>>>doing anything extra - so http://site.com/do/activities can be put into
>>>marketing materials as http://site.com/activities. Maybe we could have
>>>marketing use http://site.com/activities/index.html and then use a filter
>>>(mapped to *.html) to do a redirect to http://site.com/do/activities.
>>>Matt
>>>-----Original Message-----
>>>From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]
>>>Sent: Thursday, September 18, 2003 1:26 AM
>>>To: Struts Users Mailing List
>>>Subject: Re: Is it possible to remove *.do or /do/* from the URL
>>>
>>>The important principle here is "Web Application != Web Site". If your
>>>users feel compelled to use bookmarks and the back button in your
webapps,
>>>despite efforts to train them correctly, this is a pretty good sign that
>>>you have not provided enough suitable navigation controls in your basic
>>>UI.
>>>Craig
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: [EMAIL PROTECTED]
>>For additional commands, e-mail: [EMAIL PROTECTED]
>>
>
>
>
>
> LEGAL NOTICE
>
> This electronic mail transmission and any accompanying documents contain
> information belonging to the sender which may be confidential and legally
> privileged. This information is intended only for the use of the
> individual or entity to whom this electronic mail transmission was sent as
> indicated above. If you are not the intended recipient, any disclosure,
> copying, distribution, or action taken in reliance on the contents of the
> information contained in this transmission is strictly prohibited. If you
> have received this transmission in error, please delete the message.
Thank
> you
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]