Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 84094 invoked by uid 500); 13 Mar 2003 14:34:48 -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 84031 invoked from network); 13 Mar 2003 14:34:47 -0000 Received: from mail.s-und-n.de (212.8.217.2) by daedalus.apache.org with SMTP; 13 Mar 2003 14:34:47 -0000 Received: from mail.s-und-n.de (localhost [127.0.0.1]) by mail2.s-und-n.de (postfix) with ESMTP id C6846A28F2 for ; Thu, 13 Mar 2003 15:34:47 +0100 (CET) Received: from notes.sundn.de (ntsrv5.sundn.de [10.10.2.10]) by mail.s-und-n.de (postfix) with ESMTP id 45FC1A282F for ; Thu, 13 Mar 2003 15:34:47 +0100 (CET) Received: from hw0386 ([10.10.2.66]) by notes.sundn.de (Lotus Domino Release 5.0.8) with SMTP id 2003031315344618:7574 ; Thu, 13 Mar 2003 15:34:46 +0100 From: "Carsten Ziegeler" To: Subject: RE: [RT] Flow as a block Date: Thu, 13 Mar 2003 15:35:18 +0100 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-MIMETrack: Itemize by SMTP Server on PBSN1/Systeme und Netzwerke(Release 5.0.8 |June 18, 2001) at 13.03.2003 15:34:46, Serialize by Router on PBSN1/Systeme und Netzwerke(Release 5.0.8 |June 18, 2001) at 13.03.2003 15:34:47, Serialize complete at 13.03.2003 15:34:47 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="iso-8859-1" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Pier Fumagalli wrote: > > For what matters to me, I really can't state an opinion on > whether the flow > scripting layer should be or shouldn't be implemented as a block. > It's true > that I don't use it in all situations, so, in a very minimal or targeted > installation, I can agree that we might want not to include al the classes > required to make it work. > > But, quite frankly, I am not that happy about having a "pluggable" sitemap > syntax. > > The sitemap as I see it, is IMVHO, the very heart of Cocoon, its syntax is > that thing we want to carve in stone. > Yes, these are the problems or dangers. > Any sitemap should be validable despite the current Cocoon setup. For > example, right now, if we have (or not) the FOP block, I'll be able to > validate a sitemap, although that specific block I rely upon might be or > might not be available at deployment time. > > As I said, I have no problem if you want to move in a block all the > org.apacje.cococoon.components.flow (well, we should probably keep the > Interpreter, AbstractInterpreter and InterpreterSelector in core, but all > the rest can go), but the sitemap syntax and cocoon > mode-of-operation should > be carved in stone big time... > Hmmm, I don't agree completly. The core sitemap syntax has to be carved in stone. True. *if* we would use a different namespace for the plugins, like the flow, than the sitemap can still be validated without any problems. The application will of course not run, if your sitemap uses the flow, when the flow is not available. But the same happens, if the fop serializer is used and is not available. I agree with you, if we give the plugins the same namespace as the sitemap has. Carsten