Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 77744 invoked from network); 21 Nov 2003 19:35:11 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 21 Nov 2003 19:35:11 -0000 Received: (qmail 91149 invoked by uid 500); 21 Nov 2003 19:34:57 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 91097 invoked by uid 500); 21 Nov 2003 19:34:57 -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 91049 invoked from network); 21 Nov 2003 19:34:57 -0000 Received: from unknown (HELO out2.smtp.messagingengine.com) (66.111.4.26) by daedalus.apache.org with SMTP; 21 Nov 2003 19:34:57 -0000 X-Sasl-enc: lN4S8GIhz2oK5NuZUHi02A 1069443294 Received: from upaya.co.uk (elfriedeholmes.demon.co.uk [80.177.165.206]) by www.fastmail.fm (Postfix) with ESMTP id 3B98743A864 for ; Fri, 21 Nov 2003 14:34:54 -0500 (EST) Message-ID: <3FBE68FB.5030109@upaya.co.uk> Date: Fri, 21 Nov 2003 19:35:23 +0000 From: Upayavira User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Re: XConfPath task (was Re: MountTableMatcher) References: <3FB6248F.6040506@upaya.co.uk> <3FB8F3D2.8090102@upaya.co.uk> <3FB8FD84.7020307@leverageweb.com> <3FB91F89.8070904@upaya.co.uk> <3FB953C5.1080607@leverageweb.com> <3FBBB867.40901@upaya.co.uk> <3FBC908C.8080607@upaya.co.uk> <3FBE09CC.9030605@leverageweb.com> <3FBE0EA3.8060405@verizon.net> <3FBE298A.1030304@leverageweb.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 Jeremy Quinn wrote: > > On 21 Nov 2003, at 15:04, Geoff Howard wrote: > >> Vadim Gritsenko wrote: >> >>> Geoff Howard wrote: >>> >>>> Upayavira wrote: >>> >> >> ... >> >>>>> We could: >>>>> (1) Remove the replace-properties attribute, and replace >>>>> properties automatically in the content, and in the top level >>>>> attributes. >>>>> (2) Leave the replace-properties attribute, and only replace >>>>> properties in the top level attributes if it is set to true. >>>> >>>> >>>> How about (3) default replace-properties to true, and make it >>>> optional. >>>> >>>> If someone comes up with some valid reason that variable >>>> replacement should be turned off, they can. >>> >>> That's what is called "FS" around here ;-) >> >> >> Except that in this case it's already coded! We're talking about >> whether we should remove the existing ability to turn off this new >> feature. >> >> Ok, I shouldn't have made what I consider a current plausibility to >> sound so hypothetical. There are patches which may need to handle >> ${xxx} style data (like Jexl expressions which are meant to be >> evaluated at runtime, not at build time). Xpatch would screw these >> up if not allowed to turn off this feature. This will be rare, so I >> proposed the option (3) above to preserve the ability but not cloud >> normal usage. > > > Jexl .... yeah, sorry did not think of that .... > > regards Jeremy It is now implemented - no time to test though for the moment.... Regards, Upayavira