Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 64308 invoked by uid 500); 1 Nov 2002 19:01:35 -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 64297 invoked from network); 1 Nov 2002 19:01:34 -0000 Message-ID: <20021101190139.67174.qmail@web21203.mail.yahoo.com> Date: Fri, 1 Nov 2002 11:01:39 -0800 (PST) From: Steven Punte Subject: Re: [OT] cocoon is like windows To: cocoon-dev@xml.apache.org In-Reply-To: <9289475532EFD3118C670090272AB7F803B18E56@EAST2> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N > > So, I came to a conclusion that what Cocoon's > documentation lacks is an > ideological or conceptual papers. There's a lot of > information in mailing > lists, but it's mostly technical: how to do this or > that. Less often and > scattered is info on 'why' you do this and that in > some particular way. It's > like to tell that a car has 4 weels, but not to tell > why it has them, why > there are 4 of them. So, when a guy downloads > Cocoon, runs samples, he ends > up with a question: how to use it? I tend to agree with you here. Cocoon is excellent software, but the broader potential user community is in need of more hand-holding (i.e. they are not up for the more technical reverse engineering and research task compared to our present user community group). > Here's the idea: why not to allow bypass Web GUI in > Cocoon. Maybe sitemap > must be gone too. So, there must be means to build a > Cocoon powered system > in such a way, that I can see what components are in > Cocoon and use them > deliberately. Suppose, I launch URL: /generators/dir > and get the list of > generators. Then I say: > /generators/xsp/bla-bla@/serializer/html/ya-da-da > This will be my command line to launch a generator > then forward it to a > serializer. > Or like this: > /generators/xsp/bla-bla@/temp/a > This would store the output in the temporary URL: > /temp/a, so it can be used > instead of the generator later on. You "could" do this, but why would you want to? That is, aside from it being something "cool" can you describe a more realistic application in which this would be used? It seems to me you would just be pushing business logic into another area. __________________________________________________ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org For additional commands, email: cocoon-dev-help@xml.apache.org