That's a good question. For certain mime-types, the browser just launches external programs to deal with it, so those are a dead-end, and I don't think links would be needed. Maybe the best thing to do would be to keep things simple at this point and set a target href for the link, so that the export opens a new window. Some browsers would open the data right in the window, others may ask the user to save it, then the user can just close the window and continue on.
So, Fabrizio, I think all I would need to do is encode the query string for this new servlet request and hand it off to the servlet, without needing to worry about any links after than point. I'll definitely do this as a first pass attempt. If anyone thinks we need to handle it better than this, please let me know your ideas. John On Mon, 26 Apr 2004, Fabrizio Giustina wrote: > +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 > > > 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? > -- John York Software Engineer CareerSite Corporation ------------------------------------------------------- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 _______________________________________________ displaytag-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/displaytag-devel
