Return-Path: Delivered-To: apmail-xml-cocoon-users-archive@xml.apache.org Received: (qmail 67039 invoked by uid 500); 13 Mar 2001 08:21:57 -0000 Mailing-List: contact cocoon-users-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-users@xml.apache.org Delivered-To: mailing list cocoon-users@xml.apache.org Received: (qmail 67004 invoked from network); 13 Mar 2001 08:21:49 -0000 From: "Tagunov Anthony" To: "cocoon-users@xml.apache.org" Date: Tue, 13 Mar 2001 11:24:46 +0300 Reply-To: "Tagunov Anthony" Priority: Normal X-Mailer: PMMail 2000 Professional (2.10.2010) For Windows NT (4.0.1381;6) In-Reply-To: <3.0.5.32.20010312140803.00ab5100@urchin> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Subject: Re: more text/plain output Message-Id: X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N On Mon, 12 Mar 2001 14:08:03 -0800, Cindy Ballreich wrote: > >A couple of days ago Jonathan Fuerth suggested using XSP to change the >Content-Disposition header so that MSIE will accept text/plain output from >an XML source. I wrote an XSP file that does this and it appears to work - >at least with small amounts of XML. Using the XSP with my full XML file >(which isn't really all *that* big) gives the following error... > >java.lang.ClassFormatError: Code of a method longer than 65535 bytes I guess the reason is the following: all you put into .xml file that has is compiled into one java method (look at the repository, if intrested!) So too much code can not go there! The solution for serving long files can be one of the following: 1) use XInclude. So your main file will look like responce.setHeader.. This should work. Are you using C1 or C2? If you're using C1 then you gonna run in the following trouble: -- if this page gets served from cache, then YOU WON'T HAVE YOU DESIRED HEADER!! (we here at www.nnt.ru tried to modify Page.java to store the headers, but the solution is far not elegent and in addition we fell behind the current cocoon version with our patched files. The trouble is that you no longer can set headers with responce.setHeader(), you should do it via page.setHeader, but in an XSP page you can not get access to the Page object. So we could set our new headers only in a processor. If i could find a way to do it in XSP then in the responce taglib we could update (or whatever it is called there), but :-(((..) So the only solution is to disable caching, that is _NOT_ put boolean hasChanged(){ return true; } boolean isCacheable(){ return true; } but then, you know, it will run slowely, espcially knowing that your files are large. again we have developed some content aggregation for C1 (xinclude-style), it has got caching: but again, it is behind current versions of Cocoon and requires heavy changes to many files.. >I expect that I'm going about this all wrong. All I really want to do is >call response.setHeader and then copy the XML with new PIs pointing it to >the proper XSL file. This is the XSP that I've written... > > >xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> > > name="cocoon-process">type="xsp" > name="cocoon-process">type="xslt" > name="xml-stylesheet">href="catalog-text.xsl" >type="text/xsl" > > > > response.setHeader("Content-Disposition", "inline; >filename=kluge.txt"); > > > > > > > > > > >I'd really appreciate any pointers that would get me heading in the right >direction. > >Cindy > > > >--------------------------------------------------------------------- >Please check that your question has not already been answered in the >FAQ before posting. > >To unsubscribe, e-mail: >For additional commands, e-mail: > > --------------------------------------------------------------------- Please check that your question has not already been answered in the FAQ before posting. To unsubscribe, e-mail: For additional commands, e-mail: