In the TFS DefaultTemplate.11.1.xaml build process template, there are many attributes whose entire values are surrounded by square braces [], so a tag has the form
<tagName attributeName="[attributeValue]">
where tagName, attributeName, and attributeValue are text strings.
I cannot find any documentation for this value syntax. From the template, it appears to cause the XAML processor to evaluate the text as an expression. Is this explained somewhere?
I believe that square braces in XAML do indeed denote a value expression. I am still uncertain exactly how this denotation is supported or enforced. Possibilities include:
-XAML syntax; I think this is the most likely answer.
-A Converter implementation somewhere which detects during parsing when a value begins and ends with square braces, and evaluates the content within during processing; I think this is the second-most likely answer.
-It's possible that the square braces are actually not special characters and are valid as part of an identifier, the evaluation of the value is performed via some other as yet unknown mechanism, and the square braces are present by convention only, perhaps to indicate that the value is not a literal but an expression to be evaluated. I think this is an unlikely answer.
Supporting research:
"Expressions created in the WF designer are serialized using square brackets, which is shorthand for VisualBasicValue or VisualBasicReference"
"Hand edit the workflow XAML file to change value of the Number property to [1+2] (the square brackets denote an expression)"
"Expressions are literal values or Visual Basic code bound to arguments or properties. They contain value elements (e.g. variables, constants, literals, properties) that are combined with operations to yield a new value. Expressions are written using VB.NET syntax even if the application is in a program using C#."
"Workflows produced by designer are saved in XAML, where expressions appear enclosed in square brackets."
The last quote above is the only official documentation I have found that in any way mentions the square brace surrounding expressions as XAML attribute values, and this still does not clarify whether the designer does this merely arbitrarily and without invoking any special syntax, or if expressions must appear enclosed in square brackets according to the official XAML specification and as such the designer must do this.
It is a property that is set before in your XAML like this for example: <x:Property Name="BuildNumberFormat" Type="InArgument(x:String)" /> If you open the build process templates in VS 2012 you are able to change/customize them using Workflow.
Related
I am new to thymeleaf and I don't understand the difference between th:field="${something}" and th:field="*{something}". When to use * and when to use $?
Quoting the thymeleaf documentation
Variable expressions not only can be written in ${...} expressions,
but also in *{...} ones.
There is an important difference, though: the asterisk syntax
evaluates expressions on selected objects rather than on the whole
context variables map. This is: as long as there is no selected
object, the dollar and the asterisk syntaxes do exactly the same.
From here in the 4.3 Expressions on selections (asterisk syntax) section.
Technically the difference is that if you have selected an Object
like so th:object="${session.user}
then you can use the * for the properties of the user object
like so th:text="*{lastName}"
If you haven't selected an object they are the same.
I'd like to use a variable inside a YAML literal block scalar.
Here's what I'd like to do:
markup: |
<title>
{{ title }}
</title>
Can that be done somehow?
I appreciate that this example would be trivial to execute without using a literal block scalar, but my actual use case inside a Foundation 6 stack would contain more markup and more variables than what I'm showing here.
There is no such thing as a variable inside a literal block scalar.
First of all there are no variables in YAML (the word variable, occurs only once in the YAML specification, in an example document, nr. 2.28).
And second, this is called literal for a reason. No interpretation is done of any of the characters.
Of course it is possible that some program that loads your document does something with the text between curly braces ({}). E.g interprets it as a jinja2 template. But without knowing what such a program does or expects, it is equally valid to expect something like that for the information between angle brackets (<>).
Therefore within YAML there is no way to use variables, neither inside of literal block-style scalars, nor outside them.
As for the templating: I have worked with program that generated YAML from a template and applied templates on the loaded string scalars (by recursively walking the tree). Your example could be either.
I am doing some localization testing and I have to test for strings in both English and Japaneses. The English string might be 'Waiting time is {0} minutes.' while the Japanese string might be '待ち時間は{0}分です。' where {0} is a number that can change over the course of a test. Both of these strings are coming from there respective property files. How would I be able to check for the presence of the string as well as the number that can change depending on the test that's running.
I should have added the fact that I'm checking these strings on a web page which will display in the relevant language depending on the location of where they are been viewed. And I'm using watir to verify the text.
You can read elsewhere about various theories of the best way to do testing for proper language conversion.
One typical approach is to replace all hard-coded text matches in your code with constants, and then have a file that sets the constants which can be updated based on the language in use. (I've seen that done by wrapping the require of that file in a case statement based on the language being tested. Another approach is an array or hash for each value, enumerated by a variable with a name like 'language', which lets the tests change the language on the fly. So validations would look something like this
b.div(:id => "wait-time-message).text.should == WAIT_TIME_MESSAGE[language]
To match text where part is expected to change but fall within a predictable pattern, use a regular expression. I'd recommend a little reading about regular expressions in ruby, especially using unicode regular expressions in ruby, as well as some experimenting with a tool like Rubular to test regexes
In the case above a regex such as:
/Waiting time is \d+ minutes./ or /待ち時間は\d+分です。/
would match the messages above and expect one or more digits in the middle (note that it would fail if no digits appear, if you want zero or more digits, then you would need a * in place of the +
Don't check for the literal string. Check for some kind of intermediate form that can be used to render the final string.
Sometimes this is done by specifying a message and any placeholder data, like:
[ :waiting_time_in_minutes, 10 ]
Where that would render out as the appropriate localized text.
An alternative is to treat one of the languages as a template, something that's more limited in flexibility but works most of the time. In that case you could use the English version as the string that's returned and use a helper to render it to the final page.
Which characters are and are not allowed in a key (i.e. example in example: "Value") in YAML?
According to the YAML 1.2 specification simply advises using printable characters with explicit control characters being excluded (see here):
In constructing key names, characters the YAML spec. uses to denote syntax or special meaning need to be avoided (e.g. # denotes comment, > denotes folding, - denotes list, etc.).
Essentially, you are left to the relative coding conventions (restrictions) by whatever code (parser/tool implementation) that needs to consume your YAML document. The more you stick with alphanumerics the better; it has simply been our experience that the underscore has worked with most tooling we have encountered.
It has been a shared practice with others we work with to convert the period character . to an underscore character _ when mapping namespace syntax that uses periods to YAML. Some people have similarly used hyphens successfully, but we have seen it misconstrued in some implementations.
Any character (if properly quoted by either single quotes 'example' or double quotes "example"). Please be aware that the key does not have to be a scalar ('example'). It can be a list or a map.
Say I have a field on a datawindow that is the value of a database column ("Insert > Column). It has conditions in which it needs to be protected (Properties>General>Protect).
I want to have the field background grey when it's protect. At the moment, the only way I can work out how to do this is to copy the protect conditional, no matter how complex, substituting the 1 (protect) and 0 (not protect) for colour values.
Is there some sort of syntax I can use in the Expression field for the column's background colour that references the protect value of the column? I tried
if (column.protect=1, Grey, White)
but it returns errorous saying it expects a TRUE/FALSE condition.
Is what I'm after impossible, or is it just a matter of getting the right syntax.
Cheers.
Wow. You like complex, layered questions.
The first problem is accessing the value, which isn't done as directly as you described. As a matter of fact, you use a Describe() to get the value. The only problem with that is that it comes back as a string in the following format, with quotes around (note that we're using standard PowerScript string notation where ~t is a tab)
"<DefaultValue>~t<Expression>"
You want the expression, so you'll have to parse it out, dropping the quotes as well.
Once you've got the expression, you'll need to evaluate it for the given row. That can be done with another Describe () call, particularly:
Describe ("Evaluate('<expression>', <rownum>)")
The row number that an expression is being evaluated on can be had with the GetRow() function.
This may sound like it needs PowerScript and some interim value storage, but as long as you're willing to make redundant function calls to get a given value more than once, you can do this in an expression, something like (for an example column b):
if (Describe ("Evaluate (~"" + Mid (Describe ("b.protect"),
Pos (Describe ("b.protect"), "~t")+1,
Len (Describe ("b.protect")) - Pos (Describe ("b.protect"), "~t") - 1)
+ "~", " + String (GetRow()) + ")")='1',
rgb(128, 128, 128),
rgb(255,255,255))
This looks complex, but if you put the Mid() expression in a compute field so you can see the result, you'll see that simply parses out the Protect expression and puts it into the Describe (Evaluate()) syntax described above.
I have put one cheat into my code for simplicity. I used the knowledge that I only had single quotes in my Protect expression, and chose to put the Evaluate() expression string in double quotes. If I was trying to do this generically for any column, and couldn't assume an absence of double quotes in my Protect expression, I'd have use a global function to do a replace of any double quotes in the Protect expression with escaped quotes (~"), which I believe in your code would look like a triple tilde and a quote. Then again, if I had to make a global function call (note that global function calls in expressions can have a significant performance impact if there are a lot of rows), I'd just pass it the Describe ("column.protect") and GetRow() and build the entire expression in PowerScript, which would be easier to understand and maintain.
Good luck,
Terry.