7 Commits (24f692344e2e3be5cbbe576e4e91606774a5ad33)

Author	SHA1	Message	Date
Guillem Jover	24f692344e	TT#38200 Switch to new perl ngcp.get_hostname() function ... Change-Id: I87ca33c497e9a474abb1d57447369f74db1e7da1	8 years ago
Guillem Jover	5d35213a3a	TT#38200 Switch to new perl ngcp.get_firstname() function ... Change-Id: I0802fa8988d7bf84a1ca8caa3770e86d69ba079a	8 years ago
Guillem Jover	1ecd9f92ac	TT#38200 Switch to new perl ngcp.get_peername() function ... Change-Id: I4a669b22484c3b990ad0fc812201cd424226a96f	8 years ago
Guillem Jover	1c5e435a1e	TT#38200 Switch to new perl ngcp.get_nodename() function ... This is another good candidate to replace with a proper ngcp method, as the function is already implemented as a PERL block, and the most used "function". Change-Id: I49dc638a197a0215ea65c0a60c82c6c556aca3fa	8 years ago
Guillem Jover	711d2321ba	TT#38200 Switch to new perl ngcp.has_role function ... This replaces the old has_role Template "function" with a proper method of the ngcp object, anywhere we need to check for the host role, including other macros that could not use our previous "function" before. Which will make it possible to modify the has_role behavior in a single place, and affect all code paths. Change-Id: I73526aa77fab3dec8f33361e142164204d7c1481	8 years ago
Guillem Jover	5104409fd4	TT#38200 Document NGCP::Template->new method ... Change-Id: Ib0082ea645d07fb7da7e1a6d0dd9392fdf37e956	8 years ago
Guillem Jover	696ac4c247	TT#38200 Add support for new NGCP::Template perl module ... The perl Template::Toolkit is very rich, but its "function" support is a bit poor. The ways to do it are either via MACRO directives, or by simulating them with one function per file and then using PROCESS on these. The problem is that this is very clunky, does not support nesting, as we'd need different "argument" names for each "function", and it's quite cumbersome to use, need to assign aguments passed beforehand, and then assign back a designated return value from another variable. This is also one of the reasons some of the functions are not encapsulated, and have been inlined in various loops, because it was not possible to cleanly PROCESS them from those call sites. Instead we should use its native support for perl objects and perl subroutines, which exposes these as proper methods of a designated variable, and have none of the above mentioned problems. So we'll switch from constructs such as: argv.arg-a = variable; argv.arg-b = 'value'; PROCESS 'path-to-library-dir/function' result = out into: result = ngcp.function(variable, 'value'); In addition this might actually be faster, as it does not require processing additional files, and it's all just native perl code. This will be exposed within the NGCP templates as the ngcp object, and new member functions will start replacing our old and clunky native Template PROCESS-style library. Change-Id: Id2f0d181c695a9dd074646881b7d9de3478570af	8 years ago