From 8c422117807b9476890776c9f2e17cb5c532b4b0 Mon Sep 17 00:00:00 2001 From: jrogers1126 Date: Mon, 29 Jun 2015 16:36:23 -0500 Subject: [PATCH] change < > to < > --- docs/usingpyezlibrary.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/usingpyezlibrary.md b/docs/usingpyezlibrary.md index 55f800d..e74d465 100644 --- a/docs/usingpyezlibrary.md +++ b/docs/usingpyezlibrary.md @@ -359,7 +359,7 @@ These two features are very powerful, but are somewhat abstract concepts. To bet In this example, we’re going to build on the XML examples shown previously in the “RPC Mapping Examples” section, and show how we can use PyEZ to programmatically collect details about port states. This might feel like a simplistic use case, but this is actually the script that the author first wrote when starting out with the PyEZ library to solve a real world “on the job” customer problem. -The first thing we need to do is map the for the “show interface” command to a table structure. A table takes all of the XML output and collects into an ordered fashion. Table and view definitions are written in the YAML format, which is an easy to read format that is also programming language independent. The PyEZ library stores these definitions in the “lib/jnpr/junos/op/” directory in the folder where the PyEZ library is stored. +The first thing we need to do is map the <rpc> for the “show interface” command to a table structure. A table takes all of the XML output and collects into an ordered fashion. Table and view definitions are written in the YAML format, which is an easy to read format that is also programming language independent. The PyEZ library stores these definitions in the “lib/jnpr/junos/op/” directory in the folder where the PyEZ library is stored. First, lets have a look at the following table definition that ships with the PyEZ library. @@ -374,9 +374,9 @@ PhyPortTable: view: PhyPortView ``` -If you recall from our investigations in the “DMI and the NETCONF Protocol” the RPC command associated with “show interface” command is . The second line of the output above requests that this table definition should map to the XML output from that . We then filter down our interface list to just Fast Ethernet, Gigabit Ethernet and 10 Gigabit Ethernet interfaces (“[fge]e*”). The “item” section creates the equivalent of the table row in this data structure. By defining “physical-interface” as the “item” each interface from the XML output will be represented separately in the Table Structure. +If you recall from our investigations in the “DMI and the NETCONF Protocol” the RPC command associated with “show interface” command is <get-interface-information>. The second line of the output above requests that this table definition should map to the XML output from that <rpc-reply>. We then filter down our interface list to just Fast Ethernet, Gigabit Ethernet and 10 Gigabit Ethernet interfaces (“[fge]e*”). The “item” section creates the equivalent of the table row in this data structure. By defining “physical-interface” as the “item” each interface from the XML output will be represented separately in the Table Structure. -The last line in the output above is used to feed this table into a “view”. The view definition below takes each of the XML tags from the and maps them to dictionary keys on the left. These keys are the equivalent of columns in this data structure. +The last line in the output above is used to feed this table into a “view”. The view definition below takes each of the XML tags from the <rpc-reply> and maps them to dictionary keys on the left. These keys are the equivalent of columns in this data structure. **PhyPort View Definition:** ```yaml