I figured out an easy "workaround" to the fact that the displaytag's export feature (to XML, CSV, and Excel) doesn't work when using Tiles. The happens because the response has already been committed by Tiles (when including previous JSPs) and the displaytag is unable to set the contentType. Here's my workaround:
In struts-config.xml, create a local forward that goes directly to the JSP:
<forward name="exportList" path="/WEB-INF/pages/userList.jsp"/>
Then in your Action, add a little logic to see if you should forward to the definition or to the list:
// if exportType is a parameter, forward directly to JSP
if (request.getParameter("exportType") != null) {
if (log.isDebugEnabled()) {
log.debug("export detected, forwarding directly to list jsp");
}
return mapping.findForward("exportList");
} else {
// return a forward to the user list definition
return mapping.findForward("list");
}
Tested with displaytag 0.8.5 on Windows XP and Tomcat 4.1.27. Enjoy!
Update: This workaround will not work with displaytag 1.0b1. There is another solution using a Filter, so we'll try to incorporate that into the 1.0 release.
I've made a number of changes to struts-menu this week, and it now supports the ability to render menus via Velocity templates. This allows for easy customization and basically allows for you to create any type of navigation system you want (i.e. drop-downs, tabs, plain ol' links) etc. One of the issues I'm wrestling with is how should I package Velocity with the distribution. Usually, to integrate struts-menu into a Struts-based application, you only need to include struts-menu.jar. Now, if you want to use Velocity for your menus, you must include velocity.jar and velocity-tools.jar in your application's WEB-INF/lib. I think most users will accept this.
However, in the example app, there's a velocity.properties file and a couple example templates. This seems like an opportunity for many users to forget to include these - so I'm wondering what's the best way to package these. Should I put velocity.properties in the source tree, and initialize my VelocityMenuDisplayer using that? Should I do a check to see if the user has their own velocity.properites in WEB-INF/classes for an optional override?
Another question is should I put the sample templates (simple.html and coolmenus.html so far) in the source tree, and then use Velocity to load them from the struts-menu.jar file? Or should I package them in a menu-templates.jar file?
Basically, it all boils down to this question: If you have a project (.jar) that depends on Velocity and plugs into web applications - what is the best way to distribute your Velocity settings?
BTW, I hope to make an effort to decouple this library from Struts someday - shouldn't be too hard.
