Serge Vautour writes: >I'm not a programmer but can usually find a way to code what I want. I've >written a few basic commit & event scripts and they work. This one is getting >very long - lots of for-each loops inside loops.
The issue isn't looping, but infinite recursion. If a template calls itself (or another template that calls the first), it will hit a limit (3000 calls) that will prevent it from eating all memory on the box. So look at the call paths of your script to see which call is at fault. >This is mostly because I can't >find a way to store data in a hash in reference that data later (that's what I >would do in perl). The XSLT language (and SLAX-1.0) don't allow mutable variables, but you can build the XML equivalent of hashes by building XML content. For example: var $typedefs := { <typedef name="dnsname"> { <match> { <regex> "^[a-zA-Z0-9._-]{1,255}$"; <message> "must contain 1-255 letters, numbers and characters"; } } <typedef name="ip-address"> { <match> { <regex> "^[0-9]{1,3}\\.[0-9]{1,3}\\.[0-9]{1,3}\\.[0-9]{1,3}$"; <message> "must be a valid IP address"; } } <typedef name="ip-prefix"> { <match> { <regex> "^[0-9]{1,3}\\.[0-9]{1,3}\\.[0-9]{1,3}\\.[0-9]{1,3}/[0-9]{1,2}$"; <message> "must be a valid IP prefix"; } } } This hash can be consulted using normal XPath expressions: var $td = $typedefs/*[@name == $type]; if ($td && $td/match/regex) { var $re = jcs:regex($td/match/regex, $response); ... } The content doesn't have to be static, like this example, but could be build from other data. For example, you could take the results of the <get-chassis-inventory> RPC and turn them into a hash that maps the slot number to the fpc type. Thanks, Phil _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp