XConfPath task (was Re: MountTableMatcher)

[Upayavira <uv...@upaya.co.uk>]

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?

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.

There are other options, but these two make the most sense. What do 
people think?

Regards, Upayavira

Re: XConfPath task (was Re: MountTableMatcher)

[Jeremy Quinn <je...@media.demon.co.uk>]

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().

cool

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

OK

> 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 "${variable.name}" as *data* in 
their patch files?
It does not resemble anything in a normal sitemap etc.

regards Jeremy

Re: XConfPath task (was Re: MountTableMatcher)

[Vadim Gritsenko <va...@verizon.net>]

Upayavira 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 ;-)
>
>
> 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?


Yes, you are right. That's what we are following, more or less: add 
functionality when there is a valid use case for it. And if nobody can 
think of use case - then why to have this functionality? :)

Vadim

Re: XConfPath task (was Re: MountTableMatcher)

[Upayavira <uv...@upaya.co.uk>]

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

Re: XConfPath task (was Re: MountTableMatcher)

[Upayavira <uv...@upaya.co.uk>]

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

Re: XConfPath task (was Re: MountTableMatcher)

[Jeremy Quinn <je...@media.demon.co.uk>]

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

Re: XConfPath task (was Re: MountTableMatcher)

[Geoff Howard <co...@leverageweb.com>]

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.

Geoff

Re: XConfPath task (was Re: MountTableMatcher)

[Vadim Gritsenko <va...@verizon.net>]

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 ;-)

Vadim

Re: XConfPath task (was Re: MountTableMatcher)

[Geoff Howard <co...@leverageweb.com>]

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.

Geoff