Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 26961 invoked by uid 500); 12 Apr 2001 14:14:18 -0000 Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-dev@xml.apache.org Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 26880 invoked from network); 12 Apr 2001 14:14:17 -0000 Date: Thu, 12 Apr 2001 16:14:37 +0200 (CEST) From: giacomo X-X-Sender: To: Subject: Re: AW: [C2]: ToDo - List for going Beta In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N On Thu, 12 Apr 2001, Jeremy Quinn wrote: > At 2:07 PM +0200 12/4/01, Carsten Ziegeler wrote: > >> > 2. Cleaning up the environment > >> > We had the recent discussion about the sendRedirect() method of the > >> > Response object (same applies to the getRealPath() of the Context). > >> > The discussion about sendRedirect() showed, that most of us agreed > >> > to remove it from the Request object. But the main problem then > >> > would be porting existing applications from C1 to C2. If we leave > >> > sendRedirect() only for porting reasion, everybody will use it, and > >> > we have no chance to remove it at a later time. > >> > My suggestion is to remove the sendRedirect() from the Request. For > >> > porting reasion the HttpRequest still contains the sendRedirect(), > >> > thus casting the Request to the HttpRequest will allow the call > >> > the method. This will only work in the http environment, but for me > >> > this sounds reasonable for a fast migration. > >> > There are others methods in the environment which should be removed > >> > for same reasons as the sendRedirect(). > >> > If we agree on this, I will volunteer for it. > >> > >> We have to take the following into acount for redirect: > >> > >> 1. If the pipeline has started to output characters onto the > >> OutputStream IIRC the servlet engine will throw an Exception > >> when issuing a redirect afterwards. There will be situation where you > >> *never* will be able to redirect because of this restriction (think > >> of a pipeline containing a XSP generator and an XMLSerializer which > >> almost immediately produce output on the OutputStream). > >> > >> 2. If we allow redirects we then need a way to report that (probabbly by > >> an Exception) to the pipeline from a sitemap component that a > >> redirection has occurred to interrupt the resource production because > >> it will throw an Exception otherwise. > >> > >Yes, I think, this is another reason for officially removing sendRedirect(). > >If really the only problem with sendRedirect() is migrating projects, we > >could (and will) offer help on the migration. > > This is a really nice offer, but it is slightly more complicated .... > > The issue as it effects me is that if redirection is available, then the > authoring language that we use to build webApps (the Crudlet.org TagLib) > will contain the concept of redirection. If redirection was not available, > the language would have been designed quite differently. > > I am at the stage where I am about to re-implement the language Crudlet.org > 2.0, this has been in specification for a while. Now I know that > redirection is not going to be available in C2 from the TagLib level, I > have the chance to hopefully re-design certain aspects of the language so > then used in C1, it will use the response taglib for re-direction, while in > C2 that will be mapped in the sitemap. > > Problem is, I understand so little about the capabilities of the Sitemap at > this stage. > > I would love to have a discussion to help me understand the correct way of > implementing the Crudlet webApp, but don't want to drag you away from the > amazing work that you are doing! It seems that I have to play the devils advocate today :) Talking about me I'm probabbly at the same stage as you. I don't know about the capabilities of the Crudlet webApp. But one is for sure: We've never said to kill Cocoon 1, so this option remains for those apps which migration effort is too costly. Giacomo > > > regards Jeremy > > > > -- > ___________________________________________________________________ > > Jeremy Quinn Karma Divers > webSpace Design > HyperMedia Research Centre > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org > For additional commands, email: cocoon-dev-help@xml.apache.org > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org For additional commands, email: cocoon-dev-help@xml.apache.org