+1 for a servlet... it will probably requires a change on how the link is generated, with a new configuration property, but it should not be so difficult to write it in a way similar to the expot filter.
It absolutely has to be j2ee 1.2 compatible (no filters, no HttpServletResponseWrapper extension).
How it should work?
- encode the original query string and call the export servlet: http://.../export?"original_query_string"
- the servlet will decode the query string, wrap the request in the same way the filter does, and forward using the original query string
- take the export string and parameters fro the request and send them (the same way the export filter does)
Is this what you was thinking at?
fabrizio
Da: John York
Inviato: lun 26/04/2004 20.43
A: [EMAIL PROTECTED]
Oggetto: [displaytag-devel] export functionality
Inviato: lun 26/04/2004 20.43
A: [EMAIL PROTECTED]
Oggetto: [displaytag-devel] export functionality
I've been playing around with the export functionality and even after implementing the filter, I having issues with it. Originally, we intended on having the tag itself handle all of the details about exporting the data. Now, we've implemented a solution for Struts Tiles, that uses a response filter configured within the web.xml. Is there any reason, we shouldn't just abandon the filter approach and implement an export servlet? If we already require a change to the web.xml, at least a servlet could handle the request properly and we'd avoid all the extra JSP newlines and garbage. Regardless, the export filter isn't working very well for us, so I may have to write a servlet. Any thoughts?
