I am documenting my code using Shinx. In some files I have mathematical formulas and would like to include a reference to them. Being in the very same file this is not a problem. Using :eq:'reference'.
However, how do you cross reference to a formula from a different file? In my case Sphinx is unable to find the reference.
According to the Sphinx docs here, equation cross-referencing only works within the same document at present. I suggest submitting a bug/feature request to get this changed (assuming there isn't one already).
As a workaround, you can probably use the generic cross referencing syntax by placing a reference label immediately before the equation you want to reference (in the "other" file), like so:
.. _equation_in_other_file:
and then use something like:
:ref:` Link Title <equation_in_other_file>`
in the "current" file to reference it.
(note you need to provide an explicit link title)
It's not quite as elegant, but it should get the job done.
Related
I want to make some basic math stuff like Sum in Diagrams.net (old Draw.io).Is it possible ?
Exemple : I create a new parameter on a shape, like "Elec : T16" and make several copy on this shape. Is it possible to have a Text which can give me the total of the shape with this parameter ?
Best Regards.
I search a lot in the Diagrams.net blog but anything relevent.
This is not supported.
Regards,
I also wanted to do something similar and while it doesn't seem possible to do it completely in the software (as of v20.3.0), I did find a bit of a workaround: If you add properties to the shape data, then do File > Export As > XML, the properties will be there in the XML data. You can then count them one of two ways:
Open the XML file with a text editor like Notepad++, do a find on the value you want to count. If you choose "Find All" it will tell you how many times it appears.
Use a programming language like Python to read through the file and count the instances of that value.
Example:
I created a red circle in a new diagram, edited the text to say "RedCircle" and used Edit Data to add a property called TestValue, to which I assigned a value of 1. When I exported to XML it contained this element:
<object label="RedCircle" TestValue="1" id="6byQ5fOap-RXn7mFit_J-1">
Notes
When you export, make sure you turn off the Compressed option, this will create an unusable file.
Don't use Save As > XML, this will also use compression.
Diagrams.net natively saves in a compressed XML format, with only slight differences between that and the other compressed XML options, but it seems happy to also read in the exported uncompressed XML. I didn't test but if you go the programming route and want to take it a step further, it seems you could have the program update the value of a given "counter" element with the count, then open the XML file in diagrams.net to see the updated value and save it as a native .drawio file or publish in whatever format you like.
Edit: I discovered that under File > Properties you can turn off the compression on the actual .drawio file. If you do that you can just work from this file instead of exporting, but you might want to check the size of your file with and without it.
I'm sure a plugin could be created to do all of that within the app itself, but the other methods are enough for me at this point.
Hope this helps you!
Hi my colleague and I has been trying to get the TinyButStrong plugin openTBS to create some docx files.
We have a live system which creates some RTF files, with data from MySQL. We want to change this to docx, use openTBS. A couple of super users then in Word manage the templates.
We have a problem with creating the files, as we need to remove a line, if data isn't present.
If we in the Word template do
<w:p>[*fieldname*;magnet=w:p]*some kind of text*</w:p>
it hiddes the line if fieldname contains no data, and if if contains data, it will show the line. GREAT :-)
The problem is, that it also shows <w:p> and </w:p> when it contains data, and we don't like that.
How do we get it to stop showing these tags?
The TBS parameter ope=minv is done for thus purpose: it performs the magnet behavior but keep the field invisible (minv stands for magnet invisible).
So the solution is:
<w:p>[*fieldname*;magnet=tbs:p;ope=minv]*some kind of text*</w:p>
By the way, magnet=tbs:p is better than magnet=w:p because your template stays compatible when converted to another other format (LibreOffice).
I have two separate paths defined in my schema:
/team/{id}/people/{modified}:
get:
/team/{id}/people/{person_id}:
delete:
So these are two completely separate "things" because one is a get and one is a delete, and the second parameter name doesn't make sense as something generic. The 'get' is passing in a modified timestamp at that location and the delete is passing in an actual person identifier.
This shows up properly in Swagger UI, but the Swagger Editor is giving an error telling me that an equivalent path already exists. It's hard to just ignore it because that scatters errors all over the file making it hard to debug real issues.
What's the solution to something like this?
you should be use /team/{id}/people/delete/{person_id}:
I'm using Grunt and Assemble to create precompiled templates on my site but I need to dynamically create some sections based on information stored in client-side storage. Is there a way to exempt sections of a template from precompilation?
We can't do custom delimiters (a shortcoming of Handlebars), but there are a couple of solutions that might work for you. Neither is necessarily idiomatic, so you be the judge of how suitable these are for the project you're working on.
string replacement
You could use some custom (temporary) delimiters for the templates in the content that shouldn't be compiled, then create a block helper that will convert those delimiters back to valid handlebars expressions during compile time (I tested this for this answer and it works):
For example:
Handlebars.registerHelper("raw", function(options) {
return options.fn(this).replace(/\[\[/g, '{{').replace(/\]\]/g, '}}');
});
Then use it like this:
{{#raw}}
{{> foo }}
{{/raw}}
Inside foo.hbs, you might have something like this:
<title>[[title]]</title>
and it will render to:
<title>{{title}}</title>
This solution is hacky for sure, and you might have problems if you happen have any code examples embedded in the included content and one of the examples happens to have that syntax (like [0,1,[foo, bar]].
escaping
This solution is most likely the better way to go. Handlebars will not evaluate any templates that are preceded by \. So you can do this:
<title>\{{title}}</title>
and it will render to:
<title>{{title}}</title>
The first suggestion probably wasn't even worth adding, but hey, you never know right?
I can see the technology-independent Tridion Content Delivery Language (TCDL) link has the following parameters, which are pretty well described on SDL Live Content.
type
origin
destination
templateURI
linkAttributes
textOnFail
addAnchor
VariantId
How do we add multiple attribute-value pairs for the linkAttributes? Specifically, what do we use to escape the double quotes as well as separate pairs (e.g. if we need class="someclass" and onclick="someevent").
The separate pairs are just space delimited, like a normal series of attributes. Try XML encoding the value of linkAttributes however. So, " become "e;, etc...
If you are using some Javascript, you might take care of the Javascript quotes too, as in \".
Edit: after I figured out your real question, the answer is a lot simpler:
You should wrap the values inside your linkAttributes in single quotes. Spaces inside linkAttributes are typically handled fine; but if not, escape then with %20.
If you need something more or want something that isn't handled by the standard tcdl:ComponentLink, remember that you can always create your own TCDL tag and and use a TagHandler or TagRenderer (look them up in the docs for examples or search for Jaime's article on TagRenderer) to do precisely what you want.
My original answer was to a question you didn't ask: what is the format for TCDL tags (in general). But the explanation might still be useful to some, so remains below.
I'd suggest having a look at what format the default building blocks (e.g. the Link Resolver TBB in the Default Finish Actions) output and use that as a guide line.
This is what I could quickly get from the transport package of a published page:
<tcdl:Link type="Page" origin="tcm:5-199-64" destination="tcm:5-206-64"
templateURI="tcm:0-0-0" linkAttributes="" textOnFail="true"
addAnchor="" variantId="">Home</tcdl:Link>
<tcdl:ComponentPresentation type="Embedded" componentURI="tcm:5-69"
templateURI="tcm:5-133-32">
<span>
...
One of the things that I know from experience: your entire TCDL tag will have to be on a single line (I wrapped the lines above for readability only). Or at least that is the case if it is used to invoke a REL TagRenderer. Clearly the tcdl:ComponentPresentation tag above will span multiple lines, so that "single line rule" doesn't apply everywhere.
And that is probably the best advice: given the fact that TCDL tags are processed at multiple points in Tridion Publishing, Deployment and Delivery pipeline, I'd stick to the format that the default TBBs output. And from my sample that seems to be: put everything on a single line and wrap the values in (double) quotes.