Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 41033 invoked from network); 28 Jan 2004 07:43:59 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 28 Jan 2004 07:43:59 -0000 Received: (qmail 9223 invoked by uid 500); 28 Jan 2004 07:43:32 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 9043 invoked by uid 500); 28 Jan 2004 07:43:31 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: dev@cocoon.apache.org Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 9016 invoked from network); 28 Jan 2004 07:43:31 -0000 Received: from unknown (HELO warden.diginsite.com) (208.29.163.248) by daedalus.apache.org with SMTP; 28 Jan 2004 07:43:31 -0000 Received: from wlvims01.diginsite.com by warden.diginsite.com via smtpd (for daedalus.apache.org [208.185.179.12]) with SMTP; Tue, 27 Jan 2004 23:43:33 -0800 Received: from WLVIMS01 ([127.0.0.1]) by WLVIMS01.digitalinsight.com (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with SMTP id com for ; Tue, 27 Jan 2004 23:43:31 -0800 Received: by calexc01.diginsite.com with Internet Mail Service (5.5.2657.72) id ; Tue, 27 Jan 2004 23:43:00 -0800 Message-ID: <31DF72A980E5D511B48C000102BD868503EA81B8@calexc01.diginsite.com> From: Ralph Goers To: "'dev@cocoon.apache.org'" Subject: FW: [proposal] Cleaning up our component library Date: Tue, 27 Jan 2004 23:43:00 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N Darn. Meant for this to go to the list, not to you directly. -----Original Message----- From: Ralph Goers To: 'Joerg Heinicke ' Sent: 1/27/2004 9:06 PM Subject: RE: [proposal] Cleaning up our component library I realise I am fairly new to Cocoon and my opinion probably doesn't carry as much weight as most of yours. In many ways I agree with you, but not all. In particular, I am not in favor of removing components if their replacement requires flowscript. In my company we won't/can't use it. Our environment has special security concerns that just won't allow a scripting language - or even JSPs or XSPs for that matter. One of the things we love is that the flow can be completely implemented through the sitemap and a few custom compoents, as well as those already provided by Cocoon. We'd love to use Woody (aka Cocoon Forms), but if it can be used without FlowScript it isn't obvious. So we will be using the SimpleFormTransformer etc., for the forseeable future. One of the things I abhor about Java Open Source projects is their apparent disregard for backward compatibility. If any of you read the forum at theserverside.com about the release of Commons Collections 3.0 you will know what I am talking about. So while providing strong guidance on best practices is great, IMO removing classes that have been released should only be done after the classes have been deprecated for at least one release. Ralph -----Original Message----- From: Joerg Heinicke To: dev@cocoon.apache.org Sent: 1/27/2004 5:40 PM Subject: [proposal] Cleaning up our component library Another example or the "wrong" components as [Read|Write]DOMSessionTransformer or SourceWritingTransformer. They are not transformers in the closer sense, they just tee the pipeline. They should be completely removed and replaced with either XModuleSource and aggregation (read) or FlowScript's processPipelineTo (write). Similar as for the FileGenerator the DirectoryGenerator is "out of date", we already have the replacement in our CVS. WDYT? Joerg