Re: Is it possible to remove *.do or /do/* from the URL [solved]
Jason Lea wrote: Look good... You can probably move the vanity extension loop to be outside the main loop because you only need loop throught the extensions once. Is this going to have any issues with 'jsessionid' being added to the path? Here I go replying to my own question No, the getServletPath() does not include extra path info or query string so it should be ok. -- Jason Lea - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is it possible to remove *.do or /do/* from the URL [solved]
Look good...
You can probably move the vanity extension loop to be outside the main
loop because you only need loop throught the extensions once.
Is this going to have any issues with 'jsessionid' being added to the path?
--
Jason Lea
Matt Raible wrote:
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:
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.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Is it possible to remove *.do or /do/* from the URL [solved]
If I wanted to go way overboard, I could figure out a way to hack and struts-menu to spit out /action.html instead of /do/action. ;-) That would a great feature to make the site appear all .php! ;-) Matt -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED] Sent: Friday, September 19, 2003 2:25 PM To: Struts Users Mailing List Subject: RE: Is it possible to remove *.do or /do/* from the URL [solved] On Fri, 19 Sep 2003, Matt Raible wrote: > Date: Fri, 19 Sep 2003 14:00:46 -0500 > From: Matt Raible <[EMAIL PROTECTED]> > Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]> > To: 'Struts Users Mailing List' <[EMAIL PROTECTED]> > Subject: RE: Is it possible to remove *.do or /do/* from the URL [solved] > > 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: > > 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. > That's definitely slick. If you're targeting open source geeks, you might want to add ".php" to the list :-). > Thanks, > > Matt > Craig - 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]
Re: Is it possible to remove *.do or /do/* from the URL
It works great, especially on Mozilla, and Linux, etc. http://plugindoc.mozdev.org/faqs/flash.html .V Steve Raeburn wrote: Sadly, it's flash-based and it doesn't work in Mozilla. Steve -Original Message- From: news [mailto:[EMAIL PROTECTED] Behalf Of Vic Cekvenich Sent: September 19, 2003 5:07 AM To: [EMAIL PROTECTED] Subject: Re: Is it possible to remove *.do or /do/* from the URL The best back button solution I found with source is here: http://www.robertpenner.com/experiments/backbutton/backbutto n_code.html Click next row, next row; and then back button goes to prior row. And you do not have to worry about browser compatibility (and it works on PocketPC. Yes, I have been talking about it a lot) Got any insights on what is going to replace this protocol? Yes, html/http is so 80's; it needs a replacement. I just stayed in holiday in. They said: http://www.xmlrpc.com/directory/1568/implementations or some similar light XML based SOA. PHP, J2EE, Peal, ASP, you pick it. No client is monolithic. I will be presenting an sync. zipcode decode at an upcoming Struts-NJ meeting via .js /Struts. When the user types in zipcode, the state and city fields is filled out async. without a submit (using XML-RPC) Did I say that it is Cross platform? .V - 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]
RE: Is it possible to remove *.do or /do/* from the URL [solved]
On Fri, 19 Sep 2003, Matt Raible wrote: > Date: Fri, 19 Sep 2003 14:00:46 -0500 > From: Matt Raible <[EMAIL PROTECTED]> > Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]> > To: 'Struts Users Mailing List' <[EMAIL PROTECTED]> > Subject: RE: Is it possible to remove *.do or /do/* from the URL [solved] > > 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: > > 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. > That's definitely slick. If you're targeting open source geeks, you might want to add ".php" to the list :-). > Thanks, > > Matt > Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XForms Engines (was RE: Is it possible to remove *.do or /do/* from the URL)
On Fri, 19 Sep 2003, Joe Germuska wrote: > > I guess we'll see what happens; I'd been thinking about JSF and > XForms as complementary, but then, my thinking was at a pretty > superficial level. > They certainly can be -- writing a RenderKit for JavaServer Faces that emitted the appropriate markup would be very easy. Dealing with the input format would be just a matter of a filter that wraps the incoming request and makes it look like request parameters instead. > Joe Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Is it possible to remove *.do or /do/* from the URL
Sadly, it's flash-based and it doesn't work in Mozilla. Steve > -Original Message- > From: news [mailto:[EMAIL PROTECTED] Behalf Of Vic Cekvenich > Sent: September 19, 2003 5:07 AM > To: [EMAIL PROTECTED] > Subject: Re: Is it possible to remove *.do or /do/* from the URL > > > The best back button solution I found with source is here: > http://www.robertpenner.com/experiments/backbutton/backbutto > n_code.html > Click next row, next row; and then back button goes to > prior row. And > you do not have to worry about browser compatibility (and > it works on > PocketPC. Yes, I have been talking about it a lot) > > > >Got any insights on what is > > going to replace this protocol? > > > > Yes, html/http is so 80's; it needs a replacement. > I just stayed in holiday in. > They said: > http://www.xmlrpc.com/directory/1568/implementations or > some similar > light XML based SOA. > > PHP, J2EE, Peal, ASP, you pick it. No client is monolithic. > I will be > presenting an sync. zipcode decode at an upcoming Struts-NJ > meeting via > .js /Struts. > When the user types in zipcode, the state and city fields > is filled out > async. without a submit (using XML-RPC) > Did I say that it is Cross platform? > > .V > > > > > - > 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]
RE: Is it possible to remove *.do or /do/* from the URL [solved]
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:
(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
Re: Is it possible to remove *.do or /do/* from the URL
> > XForms is cool and all, but ... > > * Does anyone care? Even Microsoft (who would arguably need to be > convinced to implement support for this to make it a viable > real world standard)? > > * Does it deal with back buttons and bookmarks? I've read the XForms > specs several times, and still don't have any clue that they've > got any magic bullets related to these issues. > > The fundamental issues seem more related to HTTP than they are to any > particular presentation markup language. Got any insights on what is > going to replace this protocol? W3C is in processes of modularizations, from HTML to XHTML (basic, 1.0, and 1.1) and XForms as part of it. The philosophy W3C holds is to provide *pure* document-based modules according to the following observations: In XHTML 1.1 Strict DTD, it excludes any elements or attributes that are even remotely tied to presentation characteristics. For example, there is no target attribute in hyper links, no frames/frameset, etc. They are pretty much moving themselves away from real worlds - in which any documents should live inside some windows on screens, especially browser windows. The back/forward/refresh/bookmark buttons are part of browser windows. XForms would be a wrong place to look for solutions that could solve these buttons' problems, even in the future. And they are not related to HTTP protocols either. They are more like browser vendors' issues. It is conceivable that if someone could convince browser vendors, in particular MS, to disable these buttons using JavaScript or through some event handlers, such as onBack, onForward, onRefresh, and onBookmark, our Web Applications would perform much better to meet users' expectations. > > Craig > Jing Netspread Carrier http://www.netspread.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Is it possible to remove *.do or /do/* from the URL
> By that argument, GUI apps should not ever disable menu > options that are not relevant to the current state of > the computation either -- instead, they should just > leave the option enabled and "deal with it" when the user > selects it. :-) I don't think that's a fair comparison, because GUI apps have control over their interface. Web apps do not have control over their interface. If there was a standard way to tell all browsers to "disable the back button on this page" then I'd say yeah, go for it. But the nature of the web is that you do _not_ have control over the interface, and your app needs to respond to whatever the user does, rather than control what they do. > > The fact is that it is HARD to design an app for the > > web and implement it so that it works well > > in a browser. > Not only is it hard, its nearly impossible. Why do you say this? Can you give examples of situations where a web app cannot behave in an appropriate way when a user chooses to use the back button? Every situation I can think of can be handled. In some cases, maybe the best handling is to simply tell the user "you can't submit this page again, we're now going to take you back to the beginning. to avoid this, don't use the back button." But that's severe, IMO. Last resort. > Non-trivial interactive applications (I'm not taking about > adding a comment to a guest book; I'm talking about adding > an order to a database) have the same kinds of ordering > and transactional restrictions, whether you implement them > in a client-server GUI in your favorite language, or as a > webapp. It's a different beast. Even in processing an order, when the user must go down a path one step at a time, why can't the application handle the back button? What specific cases are there were using the back button just totally screws everything up in such a way that the web app could not handle it logically? Matt
RE: XForms Engines (was RE: Is it possible to remove *.do or /do/* from the URL)
I think there are server-side XForms engines, at leave Novell said they had one at the TSS this year -Original Message- From: Joe Germuska [mailto:[EMAIL PROTECTED] Sent: Friday, September 19, 2003 9:49 AM To: Struts Users Mailing List Subject: XForms Engines (was RE: Is it possible to remove *.do or /do/* from the URL) > >XForms is cool and all, but ... > >* Does anyone care? Even Microsoft (who would arguably need to be > convinced to implement support for this to make it a viable > real world standard)? For what it's worth, XML.com has a story this week on "10 Favorite XForms Engines": http://www.xml.com/pub/a/2003/09/10/xforms.html These aren't finished products, but players include IBM, Novell, and Oracle (among others.) I guess we'll see what happens; I'd been thinking about JSF and XForms as complementary, but then, my thinking was at a pretty superficial level. Joe -- -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "If nature worked that way, the universe would crash all the time." --Jaron Lanier - 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]
XForms Engines (was RE: Is it possible to remove *.do or /do/* from the URL)
XForms is cool and all, but ... * Does anyone care? Even Microsoft (who would arguably need to be convinced to implement support for this to make it a viable real world standard)? For what it's worth, XML.com has a story this week on "10 Favorite XForms Engines": http://www.xml.com/pub/a/2003/09/10/xforms.html These aren't finished products, but players include IBM, Novell, and Oracle (among others.) I guess we'll see what happens; I'd been thinking about JSF and XForms as complementary, but then, my thinking was at a pretty superficial level. Joe -- -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "If nature worked that way, the universe would crash all the time." --Jaron Lanier - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is it possible to remove *.do or /do/* from the URL
The best back button solution I found with source is here: http://www.robertpenner.com/experiments/backbutton/backbutton_code.html Click next row, next row; and then back button goes to prior row. And you do not have to worry about browser compatibility (and it works on PocketPC. Yes, I have been talking about it a lot) Got any insights on what is going to replace this protocol? Yes, html/http is so 80's; it needs a replacement. I just stayed in holiday in. They said: http://www.xmlrpc.com/directory/1568/implementations or some similar light XML based SOA. PHP, J2EE, Peal, ASP, you pick it. No client is monolithic. I will be presenting an sync. zipcode decode at an upcoming Struts-NJ meeting via .js /Struts. When the user types in zipcode, the state and city fields is filled out async. without a submit (using XML-RPC) Did I say that it is Cross platform? .V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Is it possible to remove *.do or /do/* from the URL
On Fri, 19 Sep 2003, Andrew Hill wrote: > Date: Fri, 19 Sep 2003 16:20:24 +0800 > From: Andrew Hill <[EMAIL PROTECTED]> > Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>, > [EMAIL PROTECTED] > To: Struts Users Mailing List <[EMAIL PROTECTED]> > Subject: RE: Is it possible to remove *.do or /do/* from the URL > > > But rather that some other technology will come along that avoids client > installation like a web app does, but also avoids some of the "web site" > problems, and perhaps most importantly enables developers to write richer, > more responsive GUIs. > > > Im thinking XForms > > (currently however whats out there doesnt exactly avoid the client > installation problem yet :-( ) > XForms is cool and all, but ... * Does anyone care? Even Microsoft (who would arguably need to be convinced to implement support for this to make it a viable real world standard)? * Does it deal with back buttons and bookmarks? I've read the XForms specs several times, and still don't have any clue that they've got any magic bullets related to these issues. The fundamental issues seem more related to HTTP than they are to any particular presentation markup language. Got any insights on what is going to replace this protocol? Craig > -Original Message- > From: Max Cooper [mailto:[EMAIL PROTECTED] > Sent: Friday, 19 September 2003 09:29 > To: Struts Users Mailing List > Subject: Re: Is it possible to remove *.do or /do/* from the URL > > > I agree with Matt here wholeheartedly. > > If you build an app that runs in a web browser, your app should work > properly in that environment. Asking users not to use the Back button is not > a reasonable expectation, and trying to hide it with JavaScript or other > hacks is folly. > > However, there are MANY, MANY questions about how to escape the > responsibility of making our apps work properly in a browser on this list. > And I know that the apps I have built aren't all perfect (even though I > think it is a good goal to shoot for). The fact is that it is HARD to design > an app for the web and implement it so that it works well in a browser. > > Part of me thinks the solution will NOT be that web developers all become > willing and capable of making their apps work (more) correctly in a browser. > But rather that some other technology will come along that avoids client > installation like a web app does, but also avoids some of the "web site" > problems, and perhaps most importantly enables developers to write richer, > more responsive GUIs. There are many technologies in this space, and I have > no recommendations or even any clue as to which ones have a good chance of > spreading. But I think something like this might "catch on" in a big way at > some point. > > On the other hand, perhaps a "web site" is a good model for writing our > applications. And that we should figure out strategies and design patterns > to make our apps work correctly in this environment. Web apps do have some > pretty cool advantages -- for instance, you can send someone a link to a > particular page/screen in the app. Our managers send out a link to the > timesheet we have on our intranet. You can bookmark a particular screen or > pages in an app that are most relevant to your activities for quick access. > Having a web interface also means that your app can be scripted by simply > making a HTTP requests, and perhaps looking at the responses. For these > reasons, perhaps we should come around to the idea that all web apps are web > sites, and take care to build them as such. > > Whatever the case, I think the bottom line is that if you are deploying your > app to run on a browser, it should work correctly when the user presses the > Back button, bookmarks a page, or decides to mess with the URL a bit. It > isn't always easy to make the app work properly, but there should be some > conscious thought about how to design the app so that it can work properly, > and some care in implementation to make sure that it does work as well as > the design allows. I have long wanted to write some "design patterns" to > record good solutions to common problems (or anti-patterns for bad ones) > that could be re-used by myself (when I forget, or when I need delegate) and > others. It would also be useful to describe why a certain pattern works or > why it is "good" about it to help raise awareness of the issues. But it sure > is hard to find the time... perhaps if I stopped writing long, rambling > email messages to the struts-user list I could get this done. :-) > > -Max > > - Original Message - > From: "Kruse, Matt" <[EMA
RE: Is it possible to remove *.do or /do/* from the URL
But rather that some other technology will come along that avoids client installation like a web app does, but also avoids some of the "web site" problems, and perhaps most importantly enables developers to write richer, more responsive GUIs. Im thinking XForms (currently however whats out there doesnt exactly avoid the client installation problem yet :-( ) -Original Message- From: Max Cooper [mailto:[EMAIL PROTECTED] Sent: Friday, 19 September 2003 09:29 To: Struts Users Mailing List Subject: Re: Is it possible to remove *.do or /do/* from the URL I agree with Matt here wholeheartedly. If you build an app that runs in a web browser, your app should work properly in that environment. Asking users not to use the Back button is not a reasonable expectation, and trying to hide it with JavaScript or other hacks is folly. However, there are MANY, MANY questions about how to escape the responsibility of making our apps work properly in a browser on this list. And I know that the apps I have built aren't all perfect (even though I think it is a good goal to shoot for). The fact is that it is HARD to design an app for the web and implement it so that it works well in a browser. Part of me thinks the solution will NOT be that web developers all become willing and capable of making their apps work (more) correctly in a browser. But rather that some other technology will come along that avoids client installation like a web app does, but also avoids some of the "web site" problems, and perhaps most importantly enables developers to write richer, more responsive GUIs. There are many technologies in this space, and I have no recommendations or even any clue as to which ones have a good chance of spreading. But I think something like this might "catch on" in a big way at some point. On the other hand, perhaps a "web site" is a good model for writing our applications. And that we should figure out strategies and design patterns to make our apps work correctly in this environment. Web apps do have some pretty cool advantages -- for instance, you can send someone a link to a particular page/screen in the app. Our managers send out a link to the timesheet we have on our intranet. You can bookmark a particular screen or pages in an app that are most relevant to your activities for quick access. Having a web interface also means that your app can be scripted by simply making a HTTP requests, and perhaps looking at the responses. For these reasons, perhaps we should come around to the idea that all web apps are web sites, and take care to build them as such. Whatever the case, I think the bottom line is that if you are deploying your app to run on a browser, it should work correctly when the user presses the Back button, bookmarks a page, or decides to mess with the URL a bit. It isn't always easy to make the app work properly, but there should be some conscious thought about how to design the app so that it can work properly, and some care in implementation to make sure that it does work as well as the design allows. I have long wanted to write some "design patterns" to record good solutions to common problems (or anti-patterns for bad ones) that could be re-used by myself (when I forget, or when I need delegate) and others. It would also be useful to describe why a certain pattern works or why it is "good" about it to help raise awareness of the issues. But it sure is hard to find the time... perhaps if I stopped writing long, rambling email messages to the struts-user list I could get this done. :-) -Max - Original Message - From: "Kruse, Matt" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]> Sent: Thursday, September 18, 2003 1:42 PM Subject: RE: Is it possible to remove *.do or /do/* from the URL > > The important principle here is "Web Application != Web > > Site". > > Why? In many cases, it's the same difference. These days, web "sites" > usually are web "applications" on the back-end. There are a lot of stupid > users out there. In many cases, every attempt needs to be made to cater to > them. > > > 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. > > On the contrary, I'd say that if your web application can't handle the back > button and bookmarking, then you've designed it incorrectly. ESPECIALLY if > your users want to use them :) > > When web "applications" are done right, they have nice URL's, the back > button can be used without causing any problems, and bookmarking is possible > wherever it makes sense. > >
Re: Is it possible to remove *.do or /do/* from the URL
On Thu, 18 Sep 2003, Max Cooper wrote: I'll admit it -- my opinions on this topic are undoubtedly not mainstream. But, when dealing with the realities of the technologies we have been handed (HTTP and HTML), I don't buy the "deal with whatever the user throws at you" dictum. It's not technically feasible in a general sense, and it ignores the fact that many (I won't necessarily claim "most" unless you are talking about intranet apps with controlled populations that you can train directly) are willing to learn to abide by the rules -- IF the app makes it easier to obey than to disobey. > Date: Thu, 18 Sep 2003 18:28:39 -0700 > From: Max Cooper <[EMAIL PROTECTED]> > Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]> > To: Struts Users Mailing List <[EMAIL PROTECTED]> > Subject: Re: Is it possible to remove *.do or /do/* from the URL > > I agree with Matt here wholeheartedly. > > If you build an app that runs in a web browser, your app should work > properly in that environment. Asking users not to use the Back button is not > a reasonable expectation, and trying to hide it with JavaScript or other > hacks is folly. > By that argument, GUI apps should not ever disable menu options that are not relevant to the current state of the computation either -- instead, they should just leave the option enabled and "deal with it" when the user selects it. :-) > However, there are MANY, MANY questions about how to escape the > responsibility of making our apps work properly in a browser on this list. > And I know that the apps I have built aren't all perfect (even though I > think it is a good goal to shoot for). The fact is that it is HARD to design > an app for the web and implement it so that it works well in a browser. Not only is it hard, its nearly impossible. The closest analog to the back button in a traditional GUI app is the "undo" menu option typically found on the "Edit" menu. Although it can be challenging to program the mechanics of this facility, most robust apps GUI based succeed -- for one or more of a number of reasons: * They have fine-grained control over the amount of state that gets restored (typically one edit) -- dealing with an entire page is far too coarse grained for what users really want to do. * They don't have any analog to bookmarks that let you both abandon one complete line of computation and simultaneously attempt to jump into the middle of a completely different line of computation in one fell swoop. This is a MUCH more serious issue than back buttons. * They are fundamentally modal by nature, while browseable web sites tend to be non-modal. In other words, the set of state transitions that the user can initiate is very tightly controlled by the application. The user has an illusion of control because the number of possible actions is often quite large, but random jumps throught the screens isn't one of them. > Part of me thinks the solution will NOT be that web developers all become > willing and capable of making their apps work (more) correctly in a browser. Perversely, I think we agree here :-). But the root problem isn't even the willingness of developers to do the work -- it's the fact that the goal is not achieveable without disabling some of the behaviors that people are used to when they browse web sites. > But rather that some other technology will come along that avoids client > installation like a web app does, but also avoids some of the "web site" > problems, and perhaps most importantly enables developers to write richer, > more responsive GUIs. There are many technologies in this space, and I have > no recommendations or even any clue as to which ones have a good chance of > spreading. But I think something like this might "catch on" in a big way at > some point. > Technical goodness won't make the slightest bit of difference. Widespread adoption of something other than browsers would be a marketing issue, and would have to be imposed on enough people (in the short run) to reach the critical mass necessary to attract developers to that platform. I don't see much changing in the near term -- current trends are much more evolutionary than revolutionary. > On the other hand, perhaps a "web site" is a good model for writing our > applications. And that we should figure out strategies and design patterns > to make our apps work correctly in this environment. I strongly disagree. Web sites that are friendly to browsing impose no multi-step ordering requirements on the user. Non-trivial interactive applications (I'm not taking about adding a comment to a guest book; I'm talking about adding an order to a database) have the same kinds of ordering and transactional res
Re: Is it possible to remove *.do or /do/* from the URL
I agree with Matt here wholeheartedly. If you build an app that runs in a web browser, your app should work properly in that environment. Asking users not to use the Back button is not a reasonable expectation, and trying to hide it with JavaScript or other hacks is folly. However, there are MANY, MANY questions about how to escape the responsibility of making our apps work properly in a browser on this list. And I know that the apps I have built aren't all perfect (even though I think it is a good goal to shoot for). The fact is that it is HARD to design an app for the web and implement it so that it works well in a browser. Part of me thinks the solution will NOT be that web developers all become willing and capable of making their apps work (more) correctly in a browser. But rather that some other technology will come along that avoids client installation like a web app does, but also avoids some of the "web site" problems, and perhaps most importantly enables developers to write richer, more responsive GUIs. There are many technologies in this space, and I have no recommendations or even any clue as to which ones have a good chance of spreading. But I think something like this might "catch on" in a big way at some point. On the other hand, perhaps a "web site" is a good model for writing our applications. And that we should figure out strategies and design patterns to make our apps work correctly in this environment. Web apps do have some pretty cool advantages -- for instance, you can send someone a link to a particular page/screen in the app. Our managers send out a link to the timesheet we have on our intranet. You can bookmark a particular screen or pages in an app that are most relevant to your activities for quick access. Having a web interface also means that your app can be scripted by simply making a HTTP requests, and perhaps looking at the responses. For these reasons, perhaps we should come around to the idea that all web apps are web sites, and take care to build them as such. Whatever the case, I think the bottom line is that if you are deploying your app to run on a browser, it should work correctly when the user presses the Back button, bookmarks a page, or decides to mess with the URL a bit. It isn't always easy to make the app work properly, but there should be some conscious thought about how to design the app so that it can work properly, and some care in implementation to make sure that it does work as well as the design allows. I have long wanted to write some "design patterns" to record good solutions to common problems (or anti-patterns for bad ones) that could be re-used by myself (when I forget, or when I need delegate) and others. It would also be useful to describe why a certain pattern works or why it is "good" about it to help raise awareness of the issues. But it sure is hard to find the time... perhaps if I stopped writing long, rambling email messages to the struts-user list I could get this done. :-) -Max - Original Message - From: "Kruse, Matt" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]> Sent: Thursday, September 18, 2003 1:42 PM Subject: RE: Is it possible to remove *.do or /do/* from the URL > > The important principle here is "Web Application != Web > > Site". > > Why? In many cases, it's the same difference. These days, web "sites" > usually are web "applications" on the back-end. There are a lot of stupid > users out there. In many cases, every attempt needs to be made to cater to > them. > > > 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. > > On the contrary, I'd say that if your web application can't handle the back > button and bookmarking, then you've designed it incorrectly. ESPECIALLY if > your users want to use them :) > > When web "applications" are done right, they have nice URL's, the back > button can be used without causing any problems, and bookmarking is possible > wherever it makes sense. > > IMO, there are too many lazy developers out there who do poor design and > don't consider the 'Back' button, for example, then look for cheap hacks to > stop the user from using it. Instead, they should think differently and > handle these cases. It's sometimes more work, sure, but that's part of the > job! > > Matt > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is it possible to remove *.do or /do/* from the URL
Sometime I think /struts/* is another alternative. But we have been massively *corrupted* by /*.do and might still feel not too bad :-) Jing Netspread Carrier http://www.netspread.com - Original Message - From: "Matt Raible" <[EMAIL PROTECTED]> To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]> Sent: Thursday, September 18, 2003 1:47 PM Subject: RE: Is it possible to remove *.do or /do/* from the URL > 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]
Re: Is it possible to remove *.do or /do/* from the URL
- Original Message - From: "Kruse, Matt" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]> Sent: Thursday, September 18, 2003 3:42 PM Subject: RE: Is it possible to remove *.do or /do/* from the URL > > The important principle here is "Web Application != Web > > Site". > > Why? In many cases, it's the same difference. These days, web "sites" > usually are web "applications" on the back-end. There are a lot of stupid > users out there. In many cases, every attempt needs to be made to cater to > them. > What Craig could possibly mean is that a Web Application contains most of non-idempotent actions while a Web Site contains only idempotent actions. Partitioning user actions to web servers into idempotent and non-idempotent actions is going to be our foundation theory that combines Model-1 resources and Model-2 applications into one environment as follows: Model-1 resources are grouped under idempotent modules, in which no-cache is set to false; Model-2 applications are groups under non-idempotent modules, in which no-cache is set to true and form token checking is automatically performed. Under this structure, end users could use bookmark and the browser's Back button when they navigate in idempotent modules. However, when they navigate in non-idempotent modules, they will get "Page has Expired" if they use the Back button. One problem in the theory is that when they get this message, the application flow is interrupted. The problem could be resolved in our future algorithms. > > 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. > > On the contrary, I'd say that if your web application can't handle the back > button and bookmarking, then you've designed it incorrectly. ESPECIALLY if > your users want to use them :) > We would group them (marketing stuff, bookmarks, etc.) into idempotent modules. > When web "applications" are done right, they have nice URL's, the back > button can be used without causing any problems, and bookmarking is possible > wherever it makes sense. > > IMO, there are too many lazy developers out there who do poor design and > don't consider the 'Back' button, for example, then look for cheap hacks to > stop the user from using it. Instead, they should think differently and > handle these cases. It's sometimes more work, sure, but that's part of the > job! If we find a page has a non-idempotent action, the page should be put into non-idempotent modules, in which the Refresh/Back/Forward buttons will not generate repeated actions, even end users type keyboard commands, right-click and select these commands... > > Matt > > Jing Netspread Carrier http://www.netspread.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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]
RE: Is it possible to remove *.do or /do/* from the URL
--- "Kruse, Matt" <[EMAIL PROTECTED]> wrote: > > The important principle here is "Web Application > != Web > > Site". > > Why? In many cases, it's the same difference. These > days, web "sites" > usually are web "applications" on the back-end. > There are a lot of stupid > users out there. In many cases, every attempt needs > to be made to cater to > them. Yes, in many cases you are right. For instance, Sprint PCS uses Struts and it is a public website. They have to cater to different browsers, people hitting the back button, etc. But, a lot of Struts development is being done in a closed corporate environment. My former employer had the direction that ALL of the company's applications (over 100 of them) had to be browser based. Out of the 100 applications that I have seen, nearly all of them take advantage of JavaScript to have a browser with no buttons, no navigation bars, etc. At that company, there was direct control over what was on the users desktop (IE 5.5). *I believe* that is what Craig is referring to as a 'web application'. -Blake __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Is it possible to remove *.do or /do/* from the URL
> The important principle here is "Web Application != Web > Site". Why? In many cases, it's the same difference. These days, web "sites" usually are web "applications" on the back-end. There are a lot of stupid users out there. In many cases, every attempt needs to be made to cater to them. > 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. On the contrary, I'd say that if your web application can't handle the back button and bookmarking, then you've designed it incorrectly. ESPECIALLY if your users want to use them :) When web "applications" are done right, they have nice URL's, the back button can be used without causing any problems, and bookmarking is possible wherever it makes sense. IMO, there are too many lazy developers out there who do poor design and don't consider the 'Back' button, for example, then look for cheap hacks to stop the user from using it. Instead, they should think differently and handle these cases. It's sometimes more work, sure, but that's part of the job! Matt
RE: Is it possible to remove *.do or /do/* from the URL
Cool :-)
-Original Message-
From: Blake Whitmore [mailto:[EMAIL PROTECTED]
Sent: Friday, 19 September 2003 04:21
To: Struts Users Mailing List
Subject: Re: Is it possible to remove *.do or /do/* from the URL
We've incorporated a *.fish mapping for our site :)
The client was pretty happy to see:
{sitename.com}/find.fish?guide=firstnamelastname
For finding fishing guides.
-Blake
--- "Craig R. McClanahan" <[EMAIL PROTECTED]> wrote:
> On Thu, 18 Sep 2003, Vic Cekvenich wrote:
>
> > Date: Thu, 18 Sep 2003 10:39:51 -0400
> > From: Vic Cekvenich <[EMAIL PROTECTED]>
> > Reply-To: Struts Users Mailing List
> <[EMAIL PROTECTED]>
> > To: [EMAIL PROTECTED]
> > Subject: Re: Is it possible to remove *.do or
> /do/* from the URL
> >
> > 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.
> >
>
> Using the same extension for both JSP pages and the
> action invocation will
> cause grief, but any combination of different values
> would at least work.
>
> > .V
>
> Craig
>
>
-
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
>
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
-
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]
Re: Is it possible to remove *.do or /do/* from the URL
We've incorporated a *.fish mapping for our site :)
The client was pretty happy to see:
{sitename.com}/find.fish?guide=firstnamelastname
For finding fishing guides.
-Blake
--- "Craig R. McClanahan" <[EMAIL PROTECTED]> wrote:
> On Thu, 18 Sep 2003, Vic Cekvenich wrote:
>
> > Date: Thu, 18 Sep 2003 10:39:51 -0400
> > From: Vic Cekvenich <[EMAIL PROTECTED]>
> > Reply-To: Struts Users Mailing List
> <[EMAIL PROTECTED]>
> > To: [EMAIL PROTECTED]
> > Subject: Re: Is it possible to remove *.do or
> /do/* from the URL
> >
> > 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.
> >
>
> Using the same extension for both JSP pages and the
> action invocation will
> cause grief, but any combination of different values
> would at least work.
>
> > .V
>
> Craig
>
>
-
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
>
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Is it possible to remove *.do or /do/* from the URL
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]
RE: Is it possible to remove *.do or /do/* from the URL
hehe, if you want to get them worried use *.exe ;-) -Original Message- From: Micael [mailto:[EMAIL PROTECTED] Sent: Friday, 19 September 2003 01:33 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]
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]
RE: Is it possible to remove *.do or /do/* from the URL
On Thu, 18 Sep 2003, Mainguy, Mike wrote: > Date: Thu, 18 Sep 2003 12:36:39 -0400 > From: "Mainguy, Mike" <[EMAIL PROTECTED]> > Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]> > To: 'Struts Users Mailing List' <[EMAIL PROTECTED]> > Subject: RE: Is it possible to remove *.do or /do/* from the URL > > Hmmm, that could be entertaining... Change the extension to .asp and sell it > to a microsoft shop... > That's why URLs don't really mean anything in terms of the implementing technology. For example, you could just as easily map to *.html as well. :-) Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Is it possible to remove *.do or /do/* from the URL
Hmmm, that could be entertaining... Change the extension to .asp and sell it to a microsoft shop... -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED] Sent: Thursday, September 18, 2003 12:34 PM To: Struts Users Mailing List Subject: Re: Is it possible to remove *.do or /do/* from the URL On Thu, 18 Sep 2003, Vic Cekvenich wrote: > Date: Thu, 18 Sep 2003 10:39:51 -0400 > From: Vic Cekvenich <[EMAIL PROTECTED]> > Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: Re: Is it possible to remove *.do or /do/* from the URL > > 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. > Using the same extension for both JSP pages and the action invocation will cause grief, but any combination of different values would at least work. > .V Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message and its contents (to include attachments) are the property of Kmart Corporation (Kmart) and may contain confidential and proprietary information. You are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on information contained herein is strictly prohibited. Unauthorized use of information contained herein may subject you to civil and criminal prosecution and penalties. If you are not the intended recipient, you should delete this message immediately. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is it possible to remove *.do or /do/* from the URL
On Thu, 18 Sep 2003, Vic Cekvenich wrote: > Date: Thu, 18 Sep 2003 10:39:51 -0400 > From: Vic Cekvenich <[EMAIL PROTECTED]> > Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: Re: Is it possible to remove *.do or /do/* from the URL > > 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. > Using the same extension for both JSP pages and the action invocation will cause grief, but any combination of different values would at least work. > .V Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is it possible to remove *.do or /do/* from the URL
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]
RE: Is it possible to remove *.do or /do/* from the URL
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]
Re: Is it possible to remove *.do or /do/* from the URL
On Wed, 17 Sep 2003, Matt Raible wrote: > Date: Wed, 17 Sep 2003 19:50:42 -0500 > From: Matt Raible <[EMAIL PROTECTED]> > Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]> > To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> > Subject: Is it possible to remove *.do or /do/* from the URL > > First of all: > > 1. Is it possible to remove the *.do or /do/* from the path and make all > requests /* go to the Action Servlet? While it is technically feasible to create a servlet mapping that does this, you're going to be really unhappy with the results in most cases. Just for one example, consider the fact that a "/*" mapping overrides the default "*.jsp" mapping, meaning that you would not be able to use JSP pages at all in such an environment. > 2. If so, will this mess up any image or css or script files? If the image or CSS files are local to your webapp, they will be screwed up by such a mapping. > What if they're on an external webserver and that webserver knows that > /images goes one place and /scripts goes another? > IMHO, nobody should really be giving a rip what the URL says in a web *application* (as opposed to a web site). For those that still do, I've found that the best strategy is to hide the actual URLs being used from the user. Two easy strategies to make this happen: * Have your app open a window that doesn't have a "Location" bar, so your users are not constantly distracted by the submit URLs. * Have your app create a frameset with a single frame in it, so that the displayed location never changes. 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. > Thanks, > > Matt > Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
