It seems that the inline macro pass does not work for CLI attributes.
If I render the following snippet:
:foo: crazy
:bar: pass:q,a[{foo} *world*]
hello {bar}
I get what I expect: hello crazy world
But if I pass the two attributes to the CLI (asciidoctor-pdf -a foo=crazy -a bar='pass:q,a[{foo} *world*]' foo.adoc), it does not work:
hello pass:q,a[{foo} *world*]
What can I do to make it work?
To add a little context, I plan to use antora to write the documentation of the software I am developing. I would like to define attributes in the antora-playbook.yml or the antora.yml to act as 'latex macros'.
Attributes specified on the command-line are treated as strings, not Asciidoc markup. That means that the pass macro isn't being processed.
However, by default, attributes specified on the command-line override attributes specified within a document. So, you can use your document as described above, with the attribute definitions included, and then you can run:
asciidoctor-pdf -a foo=stable foo.adoc
The command-line definition for the foo attribute overrides the in-document definition, and the result is hello stable world.
Related
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.
I want to pass in some shape or form a dictionary/map/object into my clap app. I can preprocess the dict to turn it into some csv or whatever. My problem is that I cannot find in clap docs which characters are valid for the argument values and how to escape them. Is this unrelated to clap and instead shell specific?
Can I pass something like
myApp --dicty="a=1,b=3,qwe=yxc"
?
Is this unrelated to clap and instead shell specific?
Mostly, yes. clap is going to get whatever arguments the shell has determined and will parse that.
However clap has built-in support for value sets, from the readme:
Supports multiple values (i.e. -o <val1> -o <val2> or -o <val1> <val2>)
Supports delimited values (i.e. -o=val1,val2,val3, can also change the delimiter)
If that's not sufficient, then you'll have to define dicty as a String, you will receive the string a=1,b=3,qwe=yxc (I don't think you'll receive the quotes) then you'll have to parse that yourself, either by hand (regex/split/...) or with something more advanced (e.g. the csv crate though that's likely overkill).
That seems like a somewhat odd option value though.
FWIW structopt (which builds upon clap to provide a more declarative UI, and should be part of Clap 3) doesn't exactly have support for that sort of things but can be coerced into it relatively easily: https://github.com/TeXitoi/structopt/blob/master/examples/keyvalue.rs
With some modifications would allow something like
myApp -D a=1 -D b=3 -D que=yxc
or (though see comments in linked snippet for limitations)
myApp -D a=1 b=3 que=yxc
to be collected as a vec![("a", "1"), ("b", "3"), ("que", "yxc")] from which creating a hashmap is trivial.
I am writing detailed information for each function in a class, and hope when others use my python code, they could check the info for each function, by using something like help(function_name)
For example, I have created a python file called text_preprocess.py, in this file I have created a class which includes functions.
class Preprocess():
def str_process(self, row_string):
'''
This Standford CoreNLP package requires the text input as 1 single string.
The input annotators are in you command line input.
:param row_string: The string format input for Standford CoreNLP
:return: Json format output
'''
parsed_json = self.nlp.annotate(row_string, properties={
'annotators': self.standford_annotators,
'outputFormat': 'json'
})
return parsed_json
In this function, as you can see the info is within triple quotes.
But I don't know how could other users see this info without looking into my code.
I have checked many solutions online, people use help(function_name), but it seems that they wrote the code through terminal, and then type help(function_name), many of those examples do not have class either. Using --help through command line only gives them the parameter descriptions I added through argparse....
So, if I hope others could check the info of my function without looking into the code, where and how could they do that?
Either be in the same directory as your script, or make sure your script is in one of the directories listed in sys.path (usually, the first option is easier for simple things, but if you want to do the second, use a virtualenv rather than trying to install the module system-wide).
Run pydoc3 text_preprocess to get documentation for the whole module. This recursively includes all of the items below the module, such as classes, their members, and functions.
Run pydoc3 text_preprocess.Preprocess if you just want the class.
Run pydoc3 text_preprocess.Preprocess.str_process if you just want the method.
Use Sphinx if you want nicely-formatted HTML or other formats such as PDF.
You may also want to remove that empty line at the beginning of your docstring; some docstring-parsing code may misinterpret it.
Putting triple quoted strings just below the declaration of a class or method is called documentation. You can read this using Preprocess.str_process.__doc__.
Let's say that I have a renderArg named xyz. In the groovy template, what's the syntax for using the value of the renderArg in a path expression?
For example:
href="##{'/public/stylesheets/whatever/${xyz}.css'}"
The above fails with a template compilation error (which is what I expected, really). How can I use the value of the render arg inside the path string?
I'll also need to use the arg in other path expressions (not just for a css file reference).
You cannot do it directly, but there is one workaround:
First you should have defined route to root of the application, for instance:
GET / Application.index
next you can use it in this way:
href="##{Application.index}public/stylesheets/whatever/${xyz}.css"
If you repeat the structure above very often, then you can use custom tag, to do so:
add file /app/views/tags/customlink.html(customlink is name of the tag, you can use another one),
fill the content:
##{Application.index}public/stylesheet/whatever/${_key}.css
You can use it now in this way:
href="#{customlink key:'xyz' /}"
More about custom tags you can read here
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}