(refas tag="user")/path/to/userfile.xml(/refas)
<table>
<tr>
<td>username : <user>username</user></td>
<td>first name : <user>first_name</user></td>
<td>surname : <user>sur_name</user></td>
</tr>
</table>
The refas (short for refer as) plugin builds a new plugin on the fly called "user", which extracts values from the XML file and substitutes them in the document wherever the tag exists.
The compiler would split the document up like this :
print axml(qq@(refas tag="user")/path/to/userfile.xml(/refas)@);
print qq@
<table>
<tr>
<td>username : <user>username</user></td>
<td>first name : <user>first_name</user></td>
<td>surname : <user>sur_name</user></td>
</tr>
</table>
@;
Bang! refas doesn't work anymore! The compiler doesn't know what a <user> tag is and ignores it alongside things like <table> and <tr>, and the <refas> tag doesn't have an output other than to modify the parser runtime variables to understand what a <user> tag is.
The code which would work under a compiler would have to look something like this :
(refas path="/path/to/userfile.xml")
<table>
<tr>
<td>username : <d>username</d></td>
<td>first name : <d>first_name</d></td>
<td>surname : <d>sur_name</d></td>
</tr>
</table>
(/refas)
But that is not necessarily the best way to lay the code out from an design perspective, especially if one of the <user> tags needed to be elsewhere in the document. Also the refas plugin would then also have to take input data to be modified and give an ouput, or you would have to scrap the refas tag and create a plugin called user. Thus the very act of compilation is placing constraints on the code which I designed the parser over successive code iterations to overcome/eliminate.
| 