Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 24343 invoked from network); 31 Jan 2000 21:49:17 -0000 Received: from pop.systemy.it (194.20.140.28) by 63.211.145.10 with SMTP; 31 Jan 2000 21:49:17 -0000 Received: from apache.org (pv38-pri.systemy.it [194.21.255.38]) by pop.systemy.it (8.8.8/8.8.3) with ESMTP id CAA05367 for ; Wed, 1 Jan 1997 02:56:40 +0100 Message-ID: <3895DFE2.1B805991@apache.org> Date: Mon, 31 Jan 2000 20:17:54 +0100 From: Stefano Mazzocchi Organization: Apache Software Foundation X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,it MIME-Version: 1.0 To: cocoon-dev@xml.apache.org Subject: Re: HTTP headers (redirect and so on..) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Eric SCHAEFFER wrote: > > Youps, sorry. I misunderstood something (+ I thought that if the document > was null in Engine.java, it could raise an NullPointerException or something > like that). > I'm confused... I think that setting the output to null should be discouradged. I discussed with Eric before and i think we should have a StopProcessingSignal throwable class that can be thrown to signal the end of the processing. But in case SAX is used, you should call closeDocument() and terminate that. I think we should leave the return null hack for now and thinking about correct SAX handling in the future. > (But you don't return null, you set the document variable to null in your > XSP page because the populateDocument function doesn't return anything.) ?? > But I've got another problem : XSP pages are compiled and cached in the > repository. They can be recovered by their URL. Good. > But what if it's my producer that return different XML documents depending > on the context ? That should _not_ be handled by your producer, but the sitemap should call the right producer depending on some rules or some matching class. > I wrote a producer that perform some verifications before reading the XML > file, and redirect the client to another URL when a error occures. > As the producers can't write directly in the response object, my producer > return an XML document to perform the redirect. If I return an XSP page, and > if it's already catched, it isn't recompiled and no redirect is performed... ? the redirect tells the browser to request another URI which can be handled by another XSP. I don't see the problem. Are you talking about internal redirection? > My question is : why producers can't have access to the response object ? Because they should not be able to mess with the output stream directly. We all agreed that a better Request/Response model should be defined, and that producers should have access to _some_ response methods, but not all. Niclas told me he's going to propose a better API for Request and Response objects. We should wait for his proposal before dive into this more deeply. -- Stefano Mazzocchi One must still have chaos in oneself to be able to give birth to a dancing star. Friedrich Nietzsche -------------------------------------------------------------------- Come to the first official Apache Software Foundation Conference! ------------------------- http://ApacheCon.Com ---------------------