[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