onvif python will create base variables from WSDL but not the optional elements. How do I add the optional variables to the existing definition?
as in a = create(sometype)
This defines the elements a.b and a.c.
I need to add elements a.c.d, a.c.e.g and a.c.e.h.
The short answer: It depends on what the existing variable is.
The longer answer: Since the existing variable is defined by a third party library with little to no visibility, run the code under a debugger that will tell you what the existing variable is, e.g, list, dict, etc. From that information look in the python documentation if you are not familiar with that type of variable.
Related
I have an RPGLE program that I'm trying to convert from fixed-format to free-format. In general, I know that defining entry variables is done using prototypes like so:
dcl-pr myprogram;
I#Entry1 char(5);
end-pr;
dcl-pi myprogram;
InEntry1 char(5);
end-pi;
But what I don't know is how to do this when the field is already defined. We have a standard definitions file that we copy into programs such as the one I am writing, which has the field I'm using as the enter variable already defined and copied in. In fixed-format, this is just
C *Entry PList
C Parm InEntry1
I have already tried just doing the copy before the prototype entry and leaving the specification blank, but that caused errors. I know I could just use the 'LIKE' keyword and change the variable names, but for readability's sake I would prefer to avoid doing that, and I don't know what problems that may cause down the road.
Just in case it's necessary, there are two variables I'm trying to get in: a data structure and a zoned decimal.
How can I use a variable that is already defined as an entry variable in free-format RPGLE, whether using prototypes or some other way that I do not know of?
The "right" way to handle this would be to create a new version of your standard definitions file (StdDefs==>StdDefs2) to declare the variables under a new name (perhaps with a _t suffix) and the TEMPLATE keyword.
Then in your refactored PR/PI, you use LIKE or LIKEDS.
so your original program looks somthing like
/copy StdDefs
C *Entry PList
C Parm InEntry1
Your refactored one with PR/PI looks like
/copy StdDefs2
/copy Mypr
dcl-pi myprogram;
InEntry1 like(inEntry_t);
end-pi;
Note that best practice is to have the PR in a separate member that's /COPY'd into both caller and callee.
Could not find a solution without declaring another variable with like. And assign the new variable to the old at the begenning of the program, and vice versa at the end.
I'm new to JMeter so this question may sound absolutely dumb...
I have a loop in which a variable (let's say it is called "raw") is being changed and written to file every iteration. The variable contains HTML encoded text so it has to be converted into plain text. I found out this can be done using __unescapeHtml function. When I tried using it worked but I ended up always receiving the same text as on the first iteration. Then I learned that I have to use vars.get instead of ${} to access a variable. So I changed ${__unescapeHtml("${raw}")} to ${__unescapeHtml(vars.get("raw")} which kind of helped: vars.get is getting the new value of raw each iteration but __unescapeHtml didn't work at all now - it just returns the encoded text from raw. I didn't succeded finding anything about this exact problem so I'm kind of stuck.
Ended up using
import org.apache.commons.lang3.StringEscapeUtils
...
StringEscapeUtils.unescapeHtml4(vars.get("raw"))
Don't know if it is a good way to do this but at least it works.
I assume, that you are using the expression ${...} inside a JSR-223 sampler or similar context. The user manual for JSR-223 Sampler states, that those scripts can be cached by JMeter. That is why you only get the values from the first time the context gets created.
The same is true for simple variable evaluations as ${varname}, as for function calls like ${__unescapeHtml(...)}.
The solution here is:
don't use ${...} inside of JSR-223 contexts, that might be cached.
you can however pass those expressions (${...}) into the context by using them as parameters through the input labeled Parameters on the JSR-223 Sampler – again assuming, that you are using it.
you can use the features, that your chosen JSR-223 context gives you, as you have done, by using the StringEscapeUtils#unescapeHtml4
Is there a Way to get the BuiltInParameterId (Ex:BuiltInParameter.SHEET_SIZE)
from a Parameter ElementId.
I have a number extracted from an Schedule Field (-1010106)
and I want to get the BuildInParameter-id.
Currently I am doing it like this:
BIPdic = {i.value__ : i for i in BuiltInParameter.GetValues(BuiltInParameter)}
bipid= BIPdic[-1010106]
I could not find an easier way. (Its easy, but I have to built a dictionary
from all (over 3000 BuiltInParameters)).
THX
tillbaum
I am not absolutely sure I know what you mean. Check out the description of the ElementId constructor taking a BuiltInParameter input argument.
You can also take a look at the built-in parameter checker BipChecker and its BipChecker GitHub repo. It iterates over all built-in parameter values and tries to retrieve a parameter value for each one.
That sounds pretty similar to what you are after with your dictionary.
I am trying to programmatically access all fields of some Python3 object using a combination of dir and getattr. Pseudocode below:
x = some_object()
for i in dir(x):
print(str(getattr(x, i)))
However, the Python docs (https://docs.python.org/2/library/functions.html#dir) on dir is VERY vague:
Note Because dir() is supplied primarily as a convenience for use at an interactive prompt, it tries to supply an interesting set of names more than it tries to supply a rigorously or consistently defined set of names, and its detailed behavior may change across releases.
My questions:
1) Is there a way to achieve the above more rigorously than using dir?
2) What does "interesting set of names" mean and how is it computed?
Kind of?
With custom __getattr__ and __getattribute__ implementations, an object can dynamically respond to requests for any attribute. You could have an object that has every attribute, or an object that randomly has or doesn't have the foo attribute with 50% probability every time you look at it. If you know how an object's __getattr__ and __getattribute__ work, and you know that they respond to a finite list of attribute names, then you can write your own version of dir that lists everything, but even handling the basic built-in types requires an uncomfortable number of cases. You can see the dir implementation in Objects/object.c.
The documentation gives an explanation of which attributes are considered interesting:
If the object is a module object, the list contains the names of the module’s attributes.
If the object is a type or class object, the list contains the names of its attributes, and recursively of the attributes of its bases.
Otherwise, the list contains the object’s attributes’ names, the names of its class’s attributes, and recursively of the attributes of its class’s base classes.
By "attributes", this documentation is mostly referring to the keys of its __dict__. There's also some handling for __members__ and __methods__; those are deprecated, and I don't remember what they do.
I am using a simple looping plugin so that my template looks like this:
{exp:loop_plus start="1" end="4" increment="1"}
<h3>{slide_{index}_title}</h3>
{/exp:loop_plus}
However, I am ending up with the following output:
<h3>{slide_1_title}</h3>
<h3>{slide_2_title}</h3>
<h3>{slide_3_title}</h3>
<h3>{slide_4_title}</h3>
Is there any way I can have dynamic variable names like this? I am not looking for alternative methods for building a slider, I simply would like to know if the dynamic variable names like this is possible. Thanks!
I'm assuming that Loop Plus (http://devot-ee.com/add-ons/loop-plus) sets the {index} part, so the question is what is defining {slide_1_title}...?
Assuming you have an entry field or variable with this defined, what you have is correct, but if it's not working, it means there's a parsing order issue.
Let's assume the code you supplied is wrapped in a {exp:channel:entries} tag pair, what happens is EE will try to parse the variable first, so will see: {slide_{index}_title} which doesn't exist. The {exp:loop_plus} add-on will then parse it, converting it to {slide_1_title} (but to late as channel:entries has already tried to parse it), which is what is finally output to the template.
So what you want to ensure is that EE parses {exp:loop_plus} before {exp:channel:entries}, do this using parse="inward" tag:
{exp:loop_plus start="1" end="4" increment="1" parse="inward"}
<h3>{slide_{index}_title}</h3>
{/exp:loop_plus}
This is a global EE parameter that EE uses to control parse order - you won't find it documented under the specific add-on. By adding the parameter, it means this child tag will get parsed before it's parent.
One way you could do it is to declare a preload_replace variable in your template and use it in your custom field name.
So something like:
{preload_replace:my_var_prefix="whatever"}
And then in your loop, you could then use:
{slide_{my_var_prefix}_title}