OK Andy, here's what I've found. First off, I deployed your test war file and it worked as expected. I compared your configuration to mine in terms of the filter config and tld and things seem to be the same. After more experimentation I think I see the problem, but I don't really understand why.
I am mapping both *.do and *.jsp to the ResponseOverrideFilter. In my display:table tag I am using the requestURI attribute to make all of the links point back to my action instead of the jsp. This configuration results in the suppressing of the content-type and content-length headers (on all requests, not just the export). However, if I remove the requestURI attribute the initial request to the action still suppresses the content type/length headers, but the all the links that now reference the jsp (the prev/next and export links) work properly (content type/length headers come through, export opens in Excel, etc.). So as I say, I think I see the what is happening now, but I don't get why it's working this way. Any thoughts? Scott -----Original Message----- From: Andy Pruitt [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 07, 2003 10:14 AM To: [EMAIL PROTECTED] Subject: RE: [displaytag-devel] RE: [displaytag-user] Easy workaround to T iles/Export Issue I just tested it on Tomcat 4.1.27, it worked fine. Here's the war I used, it has compiled classes and src. The writeExport looks correct, I have: protected int writeExport(String contentType, String body) throws JspException { pageContext.getRequest().setAttribute(ResponseOverrideFilter.CONTENT_OVE RRIDE_TYPE, contentType); pageContext.getRequest().setAttribute(ResponseOverrideFilter.CONTENT_OVE RRIDE_BODY, body); return SKIP_PAGE; } Maybe there is a classpath or tld issue? > -----Original Message----- > From: RMC - Scott Mitchell [mailto:[EMAIL PROTECTED] > Sent: Monday, October 06, 2003 9:06 PM > To: [EMAIL PROTECTED] > Subject: RE: [displaytag-devel] RE: [displaytag-user] Easy > workaround to T iles/Export Issue > > > Andy, thanks for the feedback. I had already integrated your > filter and TableTag class changes into the source of 1.0 > beta. I can confirm that the filter is firing (I can see the > log messages). Checking the headers with Firebird shows > something strange. The content type header is not being sent > at all! Obviously I've screwed something up while integrating > your code into the package. Here are the headers that are being sent: > > HTTP/1.x 200 OK > Expires: Thu, 01 Jan 1970 00:00:00 GMT > Date: Tue, 07 Oct 2003 01:55:04 GMT > Pragma: No-cache > Server: Apache Tomcat/4.1.24-LE-jdk14 (HTTP/1.1 Connector) > Cache-Control: no-cache > > The only real edits I had to make was to the writeExport > method of the TableTag class. I essentially just replaced the > existing code with the > following: > > > pageContext.getRequest().setAttribute(ResponseOverrideFilter.C > ONTENT_OVERRID > E_TYPE, pMimeType); > > pageContext.getRequest().setAttribute(ResponseOverrideFilter.C > ONTENT_OVERRID > E_BODY, pExportString); > return SKIP_PAGE; > > Could you send me the text of your writeExport method? > > Thanks, > Scott > > PS: I've confirmed that when I disable the filter the content > type header comes through successfully. > > -----Original Message----- > From: Andy Pruitt [mailto:[EMAIL PROTECTED] > Sent: Friday, October 03, 2003 9:12 PM > To: [EMAIL PROTECTED] > Subject: RE: [displaytag-devel] RE: [displaytag-user] Easy > workaround to T iles/Export Issue > > > It sounds as though the filter isn't catching the output. > > 1) Unless/until the fix to TableTag is committed, you have to run > the tag as the TableTag that I attached to that message. I'm > attaching compiled versions to this message; they would go in a > com/backstopsolutions/web folder. > > 2) You have to change the TLD to have it refer to: > <tagclass>com.backstopsolutions.web.TableTag</tagclass> > instead of: > <!-- <tagclass>org.displaytag.tags.TableTag</tagclass>--> > > 3) Do you see debug output? The filter is outputing a DEBUG > message on the category com.backstopsolutions.web.TableTag. > > 4) Use Firebird and the Live Http Headers. It's the bomb. > Watch the content-type that comes back from the page. > > Once/if the patch and filter are added to displaytag, you > won't go through such hoops; it would only be a question of > adding the filter mapping. > > > > -----Original Message----- > > From: RMC - Scott Mitchell [mailto:[EMAIL PROTECTED] > > Sent: Friday, October 03, 2003 9:20 AM > > To: [EMAIL PROTECTED] > > Subject: RE: [displaytag-devel] RE: [displaytag-user] Easy > > workaround to T iles/Export Issue > > > > > > Andy, I agree whole-heartedly with you! I tried a small > test the other > > night and getting the filter configured wasn't a big deal > at all. Now > > having said that I did still wind up with a problem. All the pages > > rendered fine, but when I clicked on the Excel export link the data > > was displayed directly in the browser as text. Is seemed like the > > content type either didn't get set properly, or the browser somehow > > ignored it. Any thoughts? > > > > Scott > > > > -----Original Message----- > > From: Andy Pruitt [mailto:[EMAIL PROTECTED] > > Sent: Friday, October 03, 2003 10:07 AM > > To: [EMAIL PROTECTED] > > Subject: RE: [displaytag-devel] RE: [displaytag-user] Easy > > workaround to Tiles/Export Issue > > > > > > > > The issue is broader than just Tiles; it's anytime you need > to have an > > exportable table that is not in the first page fragment to be > > processed. I've attached a test case to this email; if you go > > directly to test2.jsp export will work fine, but going to > > test.jsp and > > hitting export will output the file inline as text. > > > > It seems much more intrusive to say that: > > 1) Your table must always appear on it's own page > > 2) You must create actions for each of the export options > > 3) Your code must be tied to the internal parameter > > names from the > > taglib > > > > Than to say; > > just add this filter in web.xml if you want exports to work. > > > > > > I'm never in favor of more configuration, but if someone > has already > > gone through all of the trouble of configuring Tiles, I > don't think it > > is too outrageous for them to add a filter mapping to their web.xml. > > > > > > > > > > This will not work in the latest beta: > > > The "exportType" parameter name changes for any table to allow > > > placement of more tables on the same page. You should > check for any > > > parameter like d-????-e, (for example d-1234-e) > > > > > > See it on > > > http://www.displaytag.org/displaytag-1.0-b1-examples/example-e > > > xport.jsp > > > > > > fabrizio > > > > > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] On > > Behalf Of Matt > > > Raible > > > Sent: Friday, October 03, 2003 4:56 AM > > > To: [EMAIL PROTECTED]; > > > [EMAIL PROTECTED] > > > Subject: [displaytag-user] Easy workaround to Tiles/Export Issue > > > > > > I figured out an easy "workaround" to the fact that > > exporting 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 how I'm doing it: > > > > > > 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. > > > > > > HTH, > > > > > > Matt > > > > > > > > > > > > > > > ------------------------------------------------------- > > > This sf.net email is sponsored by:ThinkGeek > > > Welcome to geek heaven. > > > http://thinkgeek.com/sf > > > _______________________________________________ > > > displaytag-user mailing list [EMAIL PROTECTED] > > > https://lists.sourceforge.net/lists/listinfo/displaytag-user > > > > > > > > > ------------------------------------------------------- > > > This sf.net email is sponsored by:ThinkGeek > > > Welcome to geek heaven. > > > http://thinkgeek.com/sf > > > _______________________________________________ > > > displaytag-devel mailing list > [EMAIL PROTECTED] > > > https://lists.sourceforge.net/lists/listinfo/displaytag-devel > > > > > > > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by:ThinkGeek > > Welcome to geek heaven. > > http://thinkgeek.com/sf > > _______________________________________________ > > displaytag-devel mailing list [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/displaytag-devel > > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > displaytag-devel mailing list [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/displaytag-devel > > ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ displaytag-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/displaytag-devel
