 |
History
| Log In
|
|
|
|
[
Permlink
| « Hide
]
Matt Raible - 20/Sep/06 12:50 PM
As part of 2.0, we could change to use each framework's default extension - or use path-based extensions. However, this will lead to separate security.xml files for each framework, which might get confusing from an AppFuse developer/documentation standpoint. I'm open to changing to a different extension - maybe simply .htm instead of .html? I'd like to do .aspx - maybe we should ask the user community on the mailing list?
I am in favour of aspx. I find html confusing for new developers. Although html is great in hiding info from end users.
My $0.02 -- I like the .html, or would at least prefer .htm. I think it makes uses of the system seem more familiar to the end user... it appears more normal to them.
Does this bug still occur if you update the webwork.properties file and move the static scripts (such as the dojo ones) into the webwork directory? (see below -- taken from sample webwork.properties file at http://www.opensymphony.com/webwork/wikidocs/webwork.properties.html ). The static-content in webwork is intended for things like dojo scripts. ### Used by FilterDispatcher ### If true than WW serves static content from inside its jar. ### If false than the static content must be available at <context_path>/webwork webwork.serve.static=false In the case you describe I think you would have to set webwork.server.static=false and then unzip the webwork directories into your context. Or you could include your static files in the source and then build the webwork.jar.
But for me its seems like too much for a simple issue. I would like to leave webwork alone as much as possible so future upgrades are less of a debacle. In my experience users don't care about the url extension. They only care about how easy the application is to use. *For example, can I bookmark a page for later --- all you Ajax zealots. ;-) Lets leave html what what that extension implies....static html pages. Its clever to hide all the magic behind our appfuse pages but I wonder if the users care? Using .html as an extension with Struts 2.0.1 doesn't seem to cause any issues with the dojo components. Maybe this issue only applies to WebWork?
Fair enough. The .html extension definitely has coolness appeal.
P.S. I was trying to install Struts 2.0.1 on an app that was originally a Appfuse 1.9.4 build and then changed around. I seemed to have problems with Spring injected Action classes. So I have gone back to WW 2.2.4, since I really don't have time for a lot of learning/debugging. I hope its something simple I am screwing up. I am sure it is. <quote>
Using .html as an extension with Struts 2.0.1 doesn't seem to cause any issues with the dojo components. Maybe this issue only applies to WebWork? </quote> Can anybody confirm this, as I'm thinking about migrating webwork (appfuse194) to struts2 specifically because of this issue. (Also struts2 is built on dojo0.4 rather than dojo2.1) <quote>
<quote> Using .html as an extension with Struts 2.0.1 doesn't seem to cause any issues with the dojo components. Maybe this issue only applies to WebWork? </quote> Can anybody confirm this, as I'm thinking about migrating webwork (appfuse194) to struts2 specifically because of this issue. (Also struts2 is built on dojo0.4 rather than dojo2.1)</quote> I have found that It does cause the same problems in Struts 2.0.1. Please let me know if you've found a work-around... I've created a poll so everyone can vote on their favorite extension.
http://appfuse.org/pages/viewpage.action?pageId=495 You'll need to create an account and login to vote. To do this, go to View > Account > Sign Up (or login if you already have an account). Thanks! Matt The poll says: "If your preferred extension isn't listed here, please leave a comment and we'll add it." I assume you mean leave a comment on the Confluence page, but I didn't see where to do that, so I'm commenting here.
Of course .html would be great if we could swing it, but I've had the same problems with other add-on packages as well, so I think we should change it. I'd suggest .xhtml -Dale I have attached a simple filter class which works well with Spring MVC. The basic operation works on the following principles:
1) The servlet container retains responsibility for serving all static resources. This ensures optimum performance (resources can be cached, have their timestamps checked for updates, etc) and avoids any I/O nasties that might arise if the filter itself tries to read and serve up these resources. 2) The filter redirects any requests for active pages to the relevant processing chain, which includes all filters related to active content, e.g. Hibernate filter. This helps ensure that the minimum number of filters are applied to static content. 3) The filter requires reasonably sophisticated pattern matching abilities to sort active from static page requests. This implies the use of an excludes filter on top of the normal include filter provided by default as part of the servlet standard. The attached implementation is Spring MVC specific. Any request that the filter believes matches an active page are redirected to the dispatch servlet by name. All other requests are allowed to pass straight through for normal processing by the servlet container. The solution also relies on the use of the <dispatcher> filter configuration element available as of the servlet 2.4 spec to separate filtering on active page requests from those for static content, which leads me to believe the solution could be made to work for the other web frameworks. Let me know what you think. Mike. Instructions for integration: http://www.nabble.com/Re%3A-Changing-default-extension-from-*.html-to-*.---p8745725s2369.html
We should integrate this filter into supported web frameworks if possible. I used Mike's Filter to create a StaticFilter today. it works with Struts 2, but has issues with the messages.jsp - presumably because Struts doesn't get a chance to create a ValueStack and add anything to it. Read more on the Struts user mailing list:
http://www.nabble.com/Re%3A-Is-it-possible-to-get-Struts%27-FilterDispatcher-to-serve-up-static-files-p9196270.html I was able to get this working with Struts 2, Spring and Tapestry - but not JSF:
http://www.nabble.com/Using-a-StaticFilter-and-dispatching-to-FacesServlet-doesn%27t-work-tf3450338.html#a9624114 |
|||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Improvement
Resolved
Minor
.html webwork extension can get confusing
