cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Upayavira ...@upaya.co.uk>
Subject Re: XConfPath task (was Re: MountTableMatcher)
Date Fri, 21 Nov 2003 14:04:02 GMT
Vadim Gritsenko wrote:

> Geoff Howard wrote:
>
>> Upayavira wrote:
>>
>>> Jeremy Quinn wrote:
>>>
>>>> On 19 Nov 2003, at 18:37, Upayavira wrote:
>>>
>>>
>>
>> ...
>>
>>>> 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?
>>>
>>> Similarly, are there any situations in which it could cause a 
>>> problem in the top level attributes, e.g. xpath, or include-before?
>>>
>>> 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 ;-)

So, Vadim,  you'd say 'replace properties always', and if someone wants 
to switch replacement off, they can code the patch task so that it 
doesn't. I.e. add the functionality when it is needed, not when we can 
think of it.

Am I right?

Upayavira


Mime
View raw message