Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 39631 invoked from network); 11 May 2005 14:21:57 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 11 May 2005 14:21:57 -0000 Received: (qmail 82065 invoked by uid 500); 11 May 2005 14:25:27 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 81904 invoked by uid 500); 11 May 2005 14:25:26 -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 81842 invoked by uid 99); 11 May 2005 14:25:25 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: local policy) Received: from odoko.co.uk (HELO odoko.co.uk) (80.68.92.132) by apache.org (qpsmtpd/0.28) with ESMTP; Wed, 11 May 2005 07:25:25 -0700 Received: from elfriedeholmes.demon.co.uk ([80.177.165.206] helo=[10.0.0.3]) by odoko.co.uk with asmtp (Exim 4.34) id 1DVsA5-0003Mk-1r for dev@cocoon.apache.org; Wed, 11 May 2005 15:26:09 +0100 Message-ID: <428214EE.80902@odoko.co.uk> Date: Wed, 11 May 2005 15:21:34 +0100 From: Upayavira Organization: Odoko Ltd User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Re: [VOTE] CForms instruction set for jxtg rendering vs. jx-macros.xml file References: <42821005.8060301@mobilebox.pl> <42821141.2000608@odoko.co.uk> <42821430.90903@mobilebox.pl> In-Reply-To: <42821430.90903@mobilebox.pl> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Leszek Gawron wrote: > Upayavira wrote: > >> Leszek Gawron wrote: >> >>> I have refactored JXTG recently so now instructions like jx:for, >>> jx:if are defined in separate file: >>> src/block/template/java/org/apache/cocoon/template/template-instructions.xml >>> >>> >>> Right now we are rendering forms in jxtg using a macro file which is >>> kind of ugly IMO - see yourself: >>> src/blocks/forms/java/org/apache/cocoon/forms/generation/jx-macros.xml >>> >>> I could fairly easily reimplement jx-macros.xml into more elegant >>> java solution by implementing a separate set of instructions like >>> ft:widget, ft:repeater and so on. If you let me of course. >>> >>> I do not want to start a tag library war. If cforms and jxtg are core >>> features they should closely support each other. >>> >>> This is NOT the case of allowing arbitrary instruction sets to be >>> created. CForms case only. >>> >>> Plase cast your votes: >>> [ ] Yes go for it. >>> [ ] It's a bad idea - leave jx-macros.xml untouched! >>> [ ] It's not jx-macros.xml fault. CForms should be changed if current >>> solution isn't right. >> >> >> >> And have the code for these extensions in the forms block (ie. forms >> depends upon templates)? +1 > > forms block of course - just like current jx-macros.file. > >> Can your code handle that? Then +1 from me. Upayavira