In iText's DITO template designer product, I have one field which has a fairly complex calculation. In another field, I want to use the result of that calculation.
The tooltip says "Identifier used for referencing fields in calculation expressions". So I assumed if I named it blah I can use it in a calculation in another field like this: sum({{blah}},42) (e.g. add 42 to the value of blah). But if I do that I get the error
Unable to resolve reference: "{{blah}}" in node with tag: <span> and text:
The iText DITO documentation does not elaborate on this feature at all. I'm evaluating iText DITO and there does not seem to be any way to get support while evaluating the product.
Suppose I have a field with a very complex calculation. In order to reuse the calculation result, I can do the following:
Give a name to this field (in the image below I've chosen name "total")
Insert a calculation to another field (where I want to reuse "total")
Add "total" as the calculation's body:
That's it, now the total value is reused:
I think the documentation you are looking for is at https://kb.itextpdf.com/home/ditokb/latest/manuals/itext-dito-editor/calculations
You have to give the rich text element a name in the properties to be able to reference it on other rich text element and/or calculations.
See image example at https://kb.itextpdf.com/home/ditokb/files/latest/68620314/68620309/1/1660291029000/image2020-5-27_17-56-41.png
Sample Input file:
<p class="Head1"><a name="para1">Sections 87-89</a></p>
some text
<p class="Head2"><a name="para2">Sections 90-92</a></p>
some text
<p class="ParaFL"><a name="para3">Some Text1</a></p>
<p class="ParaFirstLineInd"><a name="para4">Some Text2</a></p>
For example from the sample input file, if I annotate "Sections 87-89 and Sections 90-92" as Head1".Now I want to compare the annotation type(Head1) with its class type ( class="Head1", class="Head").If annotation type is not equal to class, then I want to set a feature "class changed" for the corresponding annotation type.Similarly for "Some Text1" and "Some Text2" is annotated as ParaFL(annotation type).
It depends on how the required information is represented. I assume that the class information is represented by the HtmlTypeSystem in Ruta.
There are two language elements missing in Ruta (2.4.0) in order to solve this. The main problem is that the attribute information of html tag is stored in two separate arrays and there is not option in Ruta to jointly iterate over them. the second on is autoboxing of types to strings.
I recommend to create an analysis engine (which can also be executed from within a Ruta script), which creates new annotations with one string feature containing the required information. Then, you can compare the annotation to the feature value. Autoboxing does not convert the short type names. I would add a feature to your annotations types with the corresponding type/class values. Then, you can compare the feature values.
I have a custom page type, and the editor will have the option to enter the following
Image (from media library)
Video (from media library)
YouTube video ID
The field names are as follows
SlideImage
SlideVideo
YouTubeVideoID
So, if an editor ads a SlideImage, SlideVideo and YouTubeVideoID should not be usable. Same for SlideVideo and YouTubeVideoID.
Within the Visibility Condition fields, i'm going to assume a macro is needed for this. My logic is:
This field visible if Field A or B have data.
A possible approach can be to add an additional field, which determines the field that should be used.
Create a text field (let's say, SlideType) and use a radio button form control with your options:
image;Image
video;Video
youtube;YouTube
Tick the "Has depending fields" checkbox for this field, and tick the "Depends on another field" checkbox for the SlideImage, SlideVideo and YouTubeVideoID fields.
Your visibility conditions would then be simplified, instead of checking the values of multiple fields.
For example, the visibility condition for the SlideVideo field would be:
SlideType == "video"
This has a few benefits:
Easy to add new fields and configure the visibility conditions
Easy to check what needs to be rendered in the front-end - in your repeaters and other webparts, you can simply have conditional statements on the SlideType field to determine which field to use
Intuitive for the end user - the interface makes it clear which field is being used
Add this to Visibility condition in Page type field edit:
Fields.SlideImage.Value == String.Empty
Do not forget to set proper Has depending fields and Depends on another field properties depending on your needs. You can learn more about these properties here.
Let's say the column name on which this value of your depending field is "FirstName", so you can write in the dependent field -> Visibility Condition as
FirstName.value != ""
or
FirstName.value
You can twist the conditions for as many conditions as possible and can club more than one condition too.
I am also sharing links with you having a lot of examples from Kentico support
Dependency fields in Kentico
Using dependency fields in forms
Cheers,
Chetan
I'm trying to create a "Quicklink" document for customizing the allowed connector types between elements. Our UML Profile already exists like below:
Big version here: http://i.stack.imgur.com/kcKQT.png
And this imports as an MDG Technology just fine.
However, when I add a "Quicklink" document to the profile and import it as an MDG Technology, I get the error "Encountered an improper argument". Those of you familiar with MDG Technologies in Sparx EA knows that there is no logging of any sort as to why it failed. Unfortunately, the documentation is just as unhelpful.
Here is my Quicklink document:
//Source Element Type,Source Stereotype Filter,Target Element Type,Target Stereotype Filter,Diagram Filter,New Element Type,New Element Stereotype,New Link Type,New Link Stereotype,New Link Direction,New Link Caption,New Link & Element Caption,Create Link,Create Element,Disallow Self Connector,Exclusive Stereotype Filter + No Inherit from Metatype,Menu Group,Complexity Level,Target Must be Parent,Embed Element,Precedes Separator LEAF,Precedes Separator GROUP,Dummy Column,
Feature,ChiFeature,Requirement,ChiRequirement,,,,Realization,,to,satisfies,,TRUE,,TRUE,TRUE,Requirement,0,,,,,,
My question is, is there any way for me to find out why the Quicklink document is invalid. Alternatively, is there someone more experienced with this that can see the issue?
In answer to your first question: no, I'm afraid not. As you note, EA is not very user-friendly when it comes to debugging extensions.
Happily, I've spotted the problem: you've got too many columns. Instead of filling in a dummy value at the end you've added an additional comma, which means an extra column. Replace that with a 0 and you should be OK. (Plus, of course, there shouldn't be a comma at the end of the comment line either.)
So try
//Source Element Type,Source Stereotype Filter,Target Element Type,Target Stereotype Filter,Diagram Filter,New Element Type,New Element Stereotype,New Link Type,New Link Stereotype,New Link Direction,New Link Caption,New Link & Element Caption,Create Link,Create Element,Disallow Self Connector,Exclusive Stereotype Filter + No Inherit from Metatype,Menu Group,Complexity Level,Target Must be Parent,Embed Element,Precedes Separator LEAF,Precedes Separator GROUP,Dummy Column
Feature,ChiFeature,Requirement,ChiRequirement,,,,Realization,,to,satisfies,,TRUE,,TRUE,TRUE,Requirement,0,,,,,0
I need to show in a page a list of, let's say, person's properties that should be rendered more or less as follow:
name: Name
date: 1/1/2000
other: Other
Reading the doc they say:
The LABEL element may be used to attach information to controls.
So, is it the right tag to encompass the names of the properties like name, date...
even if there's not an <input> to associate with?
Nope, as per Quentin’s answer.
However, in HTML5, <dl> can be used for generic associations where <label> isn’t appropriate.
No.
It says that it can associate information with controls.
It does not say that it can associate information with anything else.
See also the newer (but draft) specification:
Some elements, not all of them form-associated, are categorized as
labelable elements. These are elements that can be associated with a
label element.
button input (if the type attribute is not in the hidden state) keygen
meter output progress select textarea
No, it is not correct to use the label element like that.
The important thing here is the meaning of may.
The LABEL element may be used to attach information to controls.
RFC 2119 (which the HTML4 spec follows) defines may:
May: This word, or the adjective "OPTIONAL", mean that an item is truly optional
So here, may does not mean the label element can be used for other purposes; it just means that it is not required to use a label element with controls.
As far as alternatives go, it depends what you want to achieve. If you are just trying to follow the spec closely, then I suggest using p and a strong element for each pair. If you want the data to be more meaningful to computers, you could consider using one of the Microformat specifications.
I partially agree with the answers so far but want to add that if you want to use labels for some reason, then I would display the property values in read-only controls, and then your labels will be valid.
I've done this using appropriate styling to differentiate the read-only controls from the functioning controls to avoid confusing your users. This was on a sequence of pages which built up the information gathered from the user in a wizard.
I have this link to W3C - the "Editor's Draft" as opposed to the link above which is the "Working Draft", which states that you can associate it with any element - as long as it's 'labelable' - even though this is a subsection of the Form section. It states earlier that a labelable element does not have to be within a form.
http://dev.w3.org/html5/spec/single-page.html#the-label-element