[j-nsp] understaning the copy-node in SLAX
Martin T
m4rtntns at gmail.com
Mon Feb 12 04:59:25 EST 2018
On Mon, Feb 5, 2018 at 9:15 PM, Phil Shafer <phil at juniper.net> wrote:
> Martin T writes:
>>Thanks! And this technique is useful in case cli process expects an
>>element node(for example "interface-information") to have additional
>>attribute nodes(for example "junos:style="terse"")? Does it provide
>>any advantages over statically specifying the attribute node?
>
> No, there's really no advantage. I almost didn't bother including
> it in the language; it's just there for completeness. "element
> name()" gives identical functionality.
>
>>For
>>example, here I rewrote two named templates and a match template of an
>>op script example from "Automating Junos Administration" book:
>
> Can you give a page number?
>
>>template handle-logical-intf($family) {
>> <logical-interface> {
>> for-each (*[name() != "address-family"]) {
>> copy-of .;
>> }
>> for-each (address-family[address-family-name=$family]) {
>> copy-of .;
>> }
>> }
>>}
>
> You might want:
>
> <logical-interface> {
> copy-of @*;
> for-each ...
>
> ... to copy the attributes off the current node.
>
> Using "copy-node" here gives you a means of avoiding hardcoding
> the name, but that's pretty unimportant for code like this where
> the functionality is so closely tied to the name.
>
> If the W3C had given copy-node a target xpath or an interesting
> default content template (like the identity template), then it would
> be more useful. But it doesn't.
>
> Thanks,
> Phil
Phil,
thanks for explaining this! The page number for this script, which I
mentioned, is 391.
Martin
More information about the juniper-nsp
mailing list