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.
Related
Is there any tag that tells the browser to simply print what is inside the tag, without caring about the syntax of what is inside the tag? I'm trying to print a few unicode characters, but the browser keeps giving errors, even if I paste the character directly inside of a pre tag, without using ampersands.
I'm trying to print © inside of a div tag, but that putting that character inside of a div tag results in an "improperly formatted" error (the page doesn't even show up in Mozilla Firefox, and the sentence with the copyright symbol isn't printed in Microsoft Edge).
The page is being served as application/xhtml+xml.
Here is the code:
<footer>©</footer>
and here is the error:
XML Parsing Error: not well-formed Location: http://programcode.net/ Line Number 19, Column 13:
<footer></footer>
------------^
If I do this:
<footer><pre>© </pre></footer>
then the same error occurs:
XML Parsing Error: not well-formed Location: http://programcode.net/ Line Number 19, Column 18:
<footer><pre> </pre></footer>
-----------------^
I tried declaring utf-8 and utf-32 (in both the meta tag in the xhtml file, and .htaccess), but the error still occurred.
XHTML is awesome because it uses the XML parser which is extremely strict. When you have an error you know you have an error and that you need to fix it. I've seen a person spend three days trying to figure out why Safari wouldn't work but all the other browsers worked fine (he was missing a quote around an element's attribute).
What you need to do is encode HTML entities. There are a few websites that show you the full Unicode ranges and their characters. I recommend using https://unicode-table.com/en/ because it's less intimidating.
Now once you're there you'll want to want to search for the copyright symbol.
Next you'll click the obvious symbol and you'll end up on the copyright page.
You're looking for the HTML-code (the proper terminology when speaking with other professionals is "numeric HTML entity"). Never use the loose "Entity" (©), you want to always use the numeric HTML entity (©).
So your code should look like the following:
©
XHTML, CSS and JavaScript handle HTML entities a bit differently.
For JavaScript Entities you'll need to replace the uppercase 'U' with a lowercase 'u', remove the '+'. Here is an example that you can run from any browser's web developer console:
alert('Look at my \u00A9 date!');
Note that you must have the double zeroes for the copyright symbol (removing them will break the code).
For CSS Entities it's a little simpler:
h1::after {content: '\00A9'; display: block; float: left;}
Why is this so complex?
There are eight bits to a byte (one megabit a second is really only 125,000 bytes (125 kilobytes) a second. Some characters can not by represented by a single character in code. There are multiple levels of Unicode (universal character set) but most websites are moving to UTF-8. Some languages (such as Chinese, to the best of my understanding) use a symbol for an entire word (they their "alphabet" is much longer). All these characters have to somehow be represented by code (that you do not see). There is a big move to support UTF-8 natively everywhere (especially the web). Pretty much anything above character code 127 should be encoded when using XHTML. It may or it may not work natively and that is a more advanced topic for a different question. Hopefully this will give you enough insight to get a moving and a grooving though. 😊
I'm aware that there are some languages that writes the order of some characters differently than the common latin languages. E.g.: a percentage number in English would be like "100%", while in Persian it would be "/100" (the symbol comes before the number).
Question: how to consider that in the Qt internationalization system in an intelligent way?
I first thought about this code:
myLabel->setText(tr("%1%2").arg(value).arg(tr("%")));
So what would happen is that, in the Qt Linguist, the translator would change the order of the replacement fields:
%1%2 -> in Persian translation -> %2%1
I checked that in my code and I found out that while in the normal (English) translation everything was fine, when I changed to the file containing the performed translation, a bug would occur: the number to be shown was never complete having one less number that what I had written. So e.g. if I chose "99%", it would show "%9", and if I set only "9%", I would have just "%".
The problem disappeared when I put a space between %1 and %2 both in the source code as well as in the translation (%2 %1). Since ISO xxxxx says that the % should be placed with a space between it and the correspondent number, no problem for this specific situation. But what If I wanted to have both symbols without a space between each other? How should it be done?
I confirm that the problem you described exists. However I would solve this problem in the following way:
QString sPer = QString("%%1").arg(value); // %99
QString sEng = QString("%1%").arg(value); // 99%
So that
%1% -> in Persian translation -> %%1
Put the percentage inside the string to translate, something like
myLabel->setText(tr("%%1").arg(value))
even better, I think I would add a disambiguation string (Qt "old style" comment)
myLabel->setText(tr("%%1", "Show the number with a percentage").arg(value))
or maybe a new style translation comment like this
//: Show the number with a percentage
myLabel->setText(tr("%%1").arg(value))
Translator comments have issues of their own, you might be better off using a Qt disambiguation string like the preceding example.
Putting a disambiguation string (or a translator comment) will let your translator know what they are translating...
Let the translators decide where they want to put the percentage, don't try to handle it in the code as somebody else suggested, it is not scalable, you can't start handling this in the code like that, what if you need to use another character or formatting for another language?
It might even be possible that Qt might have calls to handle number formatting but I can't seem to find them at the moment and I am not fully sure how we handle them in the Qt application I work on...
If putting a % alone doesn't work, try to precede it with \, it might be necessary to escape it, I am not sure...
We have a simple search interface which calls the search:search($query-text) function. Is there a syntax to include control for wildcarding, stemming and case sensitivity within the single text string that the function accepts? I haven't been able to find anything in the MarkLogic docs.
See the $options parameter and the <term> and <term-option> constraint at https://docs.marklogic.com/search:search . There is a guide at http://developer.marklogic.com/learn/2009-07-search-api-walkthrough
and some details http://developer.marklogic.com/learn/2009-07-search-api-walkthrough#ndbba3437f320a4a4
I don't know of any existing syntax for those options, aside from the built-in behavior of turning on wildcards when a term contains '*' or '?' and turning on case-sensitivity when the term contains capital letters.
You could develop a syntax. Implementing it might involve a custom parser along the lines of https://github.com/mblakele/xqysp then feeding the resulting cts:query into search:resolve.
Piggybacking on Eric Bloch's answer... you can always dynamically construct your node based on input in the user interface.
For example, I often do this in order to separate the facet selection portion of the query from the text search portion and put the facet selection query in the additional-query element in the options node.
I've tried to find the answer in other questions, and none of the "standard" answers are working, so I'm hoping someone can either point me to where this has already been answered, or can tell me how to do this.
I have a large file with multiple documents within it. For a sample, assume something like this
DOCUMENT_IDENTIFIER 123400000000000000000123457 OTHER STUFF HERE
LINE WITH STUFF HERE
LINE WITH STUFF HERE
DOCUMENT_IDENTIFIER 123500000000000000000127456 OTHER STUFF HERE
LINE WITH STUFF HERE
LINE WITH STUFF HERE
Now, I'll need to preserve everything in the DOCUMENT_IDENTIFIER Line starting with the first 0 through the 123 (or 127 in the second Document) That header line, plus the all the LINE WITH STUFF HERE lines below it should make up one Document, and a new document should start at the second DOCUMENT_IDENTIFIER line.
When I attempt to use the standard Debatching techniques, the pipeline fails: either it just fails completely (when, for instance, I try to define a header and body schemas for the pipeline) or it never starts the second document (if I try just a body schema).
I'm certain this is something fairly simple, but I'm completely missing how to get it done. Any suggestions/direction would be welcome.
If it matters, I'm stuck on BT2006 R2, at current.
What does your Body Schema look like? I would start getting that right and make sure that you have something that will create xml with separate records of all the "DOCUMENT_IDENTIFIER 1234" records.
I would use the "DOCUMENT_IDENTIFIER "1234 bit as the Tag Identifier, and then I would set the Tag Offset to 4, to avoid the first 4 characters.
You should have a
RecordForDocumentIdentifiers (Root of your Schema) Group Maxoccurs=*
RecordForDocumentIdentifier (Set the Tag Identifier here)
Fields for the columns you want to parse
RecordForOtherLines Group Maxoccurs=*
RecordForOtherLine Maxoccurs=* or whatever your rules are.
Fields for the columns of other lines
When that seems to parse your example okay, and generate the XML you want, I would start creating my header and body schemas from that. I know it is 2 steps, but it takes some of the guesswork out of it.
I guess the Header schema would be picked from the RecordDocumentIdentifier and the body would be RecordForOtherLines (The outer record for that).
I hope that helps. If not, post your actual file and schema and let us take a look at it.
I am trying to work out the overhead of the ASP.NET auto-naming of server controls. I have a page which contains 7,000 lines of HTML rendered from hundreds of nested ASP.NET controls, many of which have id / name attributes that are hundreds of characters in length.
What I would ideally like is something that would extract every HTML attribute value that begins with "ctl00" into a list. The regex Find function in Notepad++ would be perfect, if only I knew what the regex should be?
As an example, if the HTML is:
<input name="ctl00$Header$Search$Keywords" type="text" maxlength="50" class="search" />
I would like the output to be something like:
name="ctl00$Header$Search$Keywords"
A more advanced search might include the element name as well (e.g. control type):
input|name="ctl00$Header$Search$Keywords"
In order to cope with both Id and Name attributes I will simply rerun the search looking for Id instead of Name (i.e. I don't need something that will search for both at the same time).
The final output will be an excel report that lists the number of server controls on the page, and the length of the name of each, possibly sorted by control type.
Quick and dirty:
Search for
\w+\s*=\s*"ctl00[^"]*"
This will match any text that looks like an attribute, e.g. name="ctl00test" or attr = "ctl00longer text". It will not check whether this really occurs within an HTML tag - that's a little more difficult to do and perhaps unnecessary? It will also not check for escaped quotes within the tag's name. As usual with regexes, the complexity required depends on what exactly you want to match and what your input looks like...
"7000"? "Hundreds"? Dear god.
Since you're just looking at source in a text editor, try this... /(id|name)="ct[^"]*"/
Answering my own question, the easiest way to do this is to use BeautifulSoup, the 'dirty HTML' Python parser whose tagline is:
"You didn't write that awful page. You're just trying to get some data out of it. Right now, you don't really care what HTML is supposed to look like. Neither does this parser."
It works, and it's available from here - http://crummy.com/software/BeautifulSoup
I suggest xpath, as in this question