Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <3FB8CA7E.7000005@upaya.co.uk>
Date: Mon, 17 Nov 2003 13:17:50 +0000
From: Upayavira <uv@upaya.co.uk>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.4) Gecko/20030624
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: MountTableMatcher
References: <bp0hi5$ulk$1@sea.gmane.org>
 <LKENJPKDAIKAPKHEOCMMEECDGDAA.cziegeler@s-und-n.de>
 <bp2ku6$pu0$1@sea.gmane.org> <3FB6248F.6040506@upaya.co.uk>
 <3FB6D5F0.3090805@leverageweb.com> <3FB8AF3C.2030003@upaya.co.uk>
 <3FB8B377.8070405@leverageweb.com> <3FB8B651.2050309@fwbo.org>
 <3FB8B8A6.6020301@upaya.co.uk>
In-Reply-To: <3FB8B8A6.6020301@upaya.co.uk>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

After this bit of code turned up, I couldn't resist giving it a go.

I now have a XConfToolTask that will replace properties if 
replace-properties in the top level element is set to true.

All I've now got to do is work out how to get the task to act on the 
root sitemap in all circumstances. So, some digging into the build 
process is required.

Regards, Upayavira

Upayavira wrote:

> Just had an offer of the following code over at ant-dev, which should 
> do it nicely (came with an 'untested' disclaimer though).
>
>  public void replaceProperties(Node n) throws DOMException {
>    switch (n.getNodeType()) {
>      case Node.ATTR_NODE:
>      case Node.CDATA_SECTION_NODE:
>      case Node.TEXT_NODE: {
>        n.setValue(getProject().replaceProperties(n.getNodeValue()));
>        break;
>      }
>      case Node.DOCUMENT_NODE:
>      case Node.DOCUMENT_FRAGMENT_NODE:
>      case Node.ELEMENT_NODE: {
>        Node child = n.getFirstChild();
>        while (child != null) {
>          replaceProperties(child);
>          child = child.getNextSibling();
>        }
>        break;
>      }
>      default: {
>        // ignore all other node types
>      }
>    }
>  }
>
> Regards, Upayavira
>
> Upayavira wrote:
>
>> Geoff Howard wrote:
>>
>>>>> No, XPatch doesn't handle properties expansion now.  I looked 
>>>>> briefly at how to add support for this and didn't get it worked 
>>>>> out.  I don't know Ant internals much at all - maybe someone more 
>>>>> familiar would know better.
>>>>
>>>>
>>>>
>>>> I've just asked on ant-dev, and was told:
>>>>
>>>> String org.apache.tools.ant.Project.replaceProperties(String value)
>>>
>>>
>>>
>>> Ok, I tried the other option which looked cleaner - they have a 
>>> subclass of Reader which replaces properties on the way in.  I tried 
>>> it again the other night and found that it throws an NPE when the 
>>> task runs.  Unfortunately for some reason the line number of the NPE 
>>> isn't preserved in the stack trace. 
>>
>>
>>
>> 'The other solution?'
>>
>>>> So, from looking at the xpatch task, we would have to use this 
>>>> replaceProperties method on each attribute and text value of each 
>>>> node in the patch file.
>>>
>>>
>>>
>>> Hmm, I'll look at that solution.  I was thinking of slurping the 
>>> whole patch file into a string, running replaceProperties on it, and 
>>> creating an InputStream from the string to pass to builder.parse().   
>>
>>
>>
>> That's what Jan Materne on ant-dev suggested too. He's also just 
>> recommended org.apache.tools.ant.util.DOMElementWriter, which might 
>> help.
>>
>>>> We could add a 'replace-properties' top level element, which says 
>>>> whether this should be done.
>>>>
>>>>> I haven't followed the specific context here but would love to see 
>>>>> it added too.
>>>>
>>>>
>>>>
>>>> I'm a bit busy here, any chance you could look into it, Geoff?
>>>>
>>>> It would be really cool, it would mean that you can mount your site 
>>>> without having to touch the root sitemap at all.
>>>
>>>
>>>
>>> I can't look into it more now but can pick it up in the next few days.
>>
>>
>>
>> Great. Lets play a 'who gets there first' game.
>>
>> Regards, Upayavira
>>
>>
>>
>
>
>