cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Quinn <>
Subject Re: XConfPath task (was Re: MountTableMatcher)
Date Fri, 21 Nov 2003 10:53:45 GMT

On 20 Nov 2003, at 09:59, Upayavira wrote:

> Jeremy Quinn wrote:
>> On 19 Nov 2003, at 18:37, Upayavira wrote:
>>> Jeremy,
>>> Splendid article. Stuff I've been thinking about a lot recently too.
>>> Just one useful quote from the Ant manual:
>>> <property environment="env"/>
>>> <echo message="Number of Processors = ${env.NUMBER_OF_PROCESSORS}"/>
>>> <echo message="ANT_HOME is set to = ${env.ANT_HOME}"/>
>>> With this, you can get at ${env.COCOON_HOME}, etc.
>> Thanks Upayavira
>> Did you read the bit earlier about the scheme having a flaw because 
>> of no variable substitution in the <xmap> tag's attributes?
> No I didn't.
>> How difficult would it be to add this?
> Coding-wise, pretty trivial, just wrap each string with 
> getProject().replaceProperties().


> Before we do this, I think we should sort out a few details, following 
> on from a comment from Vadim.


> Do we want to automatically replace properties, and remove the 
> replace-properties attribute? Are there any situations in which this 
> could cause a problem?

Not that I can think of

> Similarly, are there any situations in which it could cause a problem 
> in the top level attributes, e.g. xpath, or include-before?

Again, I cannot think of any

> 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.
> There are other options, but these two make the most sense. What do 
> people think?

I personally go for option 1.

Who is going to need a string like "${}" as *data* in 
their patch files?
It does not resemble anything in a normal sitemap etc.

regards Jeremy

View raw message