Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 81070 invoked from network); 6 Oct 2006 20:45:55 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 6 Oct 2006 20:45:55 -0000 Received: (qmail 70143 invoked by uid 500); 6 Oct 2006 20:45:53 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 69954 invoked by uid 500); 6 Oct 2006 20:45:52 -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 List-Id: Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 69943 invoked by uid 99); 6 Oct 2006 20:45:52 -0000 Received: from idunn.apache.osuosl.org (HELO idunn.apache.osuosl.org) (140.211.166.84) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 06 Oct 2006 13:45:52 -0700 X-ASF-Spam-Status: No, hits=0.0 required=5.0 tests= Received: from [195.13.58.165] ([195.13.58.165:64839] helo=caraldi.com) by idunn.apache.osuosl.org (ecelerity 2.1.1.8 r(12930)) with ESMTP id 51/AB-24193-970C6254 for ; Fri, 06 Oct 2006 13:45:47 -0700 Received: from anyware-tech.com (laf31-2-82-224-106-41.fbx.proxad.net [82.224.106.41]) by caraldi.com (Postfix) with ESMTP id 073D66142 for ; Fri, 6 Oct 2006 22:45:43 +0200 (CEST) Received: by anyware-tech.com (Postfix, from userid 1002) id 9B3084183B; Fri, 6 Oct 2006 22:45:42 +0200 (CEST) Date: Fri, 6 Oct 2006 22:45:42 +0200 From: Jean-Baptiste Quenot To: dev@cocoon.apache.org Subject: Re: RFC: CForms + Dojo: the way forward Message-ID: <20061006204541.GD5338@palombe.anyware> Mail-Followup-To: dev@cocoon.apache.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: mutt-ng/devel-r804 (Linux) X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Hello Jeremy, This is a nice CForms roadmap indeed. See my comment below: * Jeremy Quinn: > 3. We have two templating systems, there are incompatibilities > between them and different capabilities, can we deprecate one? > > Conclusion: the JXMacro generation technique seems to be more > popular and capable. We should if possible deprecate the use of > the FormsTransformer, adding any missing functionality to the > JXMacro lib. Before we decide this, we need an accurate idea of > all compatibility and any performance differences between the > two. We need to write some docs explaining the migration path. The old JXTemplateGenerator is the cause of performance problems when using the CForms's JX macros. So deprecating CForms transformer also means switching from the old JXTG to the new one. -- Jean-Baptiste Quenot aka John Banana Qwerty http://caraldi.com/jbq/