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.
Related
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
I have one Wicket text property in the WicketApplicationProperties.properies
<entry key="dataMniejszaNizMinimalna">Wybrano datę, która jest mniejsza niż minimalna akceptowalna data '${minimalnaData}'. Nie można zapisać danych."</entry>
How to substitute a parameter {minimalnaData} with a use of a class
StringResourceModel. I don't want to create any models i want to just display a message with provided one attribute. The Wicket StringResourceModel is so complicated.
new StringResourceModel(resourceKey).setParameters(params)
how to provide this one parameter is a simplest way.
The simplest way could be:
new StringResourceModel(resourceKey, this, Model.ofMap(Map.of("minimalnaData", "some value")))
The model object could be a Java Bean or a java.util.Map.
StringResourceModel also supports java.text.MessageFormat. You can use its #setParameters() method to pass an array of values for the placeholders.
I think wicket:message should fit your need. Take a look at the wiki:
https://cwiki.apache.org/confluence/display/WICKET/Wicket%27s+XHTML+tags
You can nest components within textual content.
Not declaring the field type brings the advantage that Symfony infers the required and maxlength attribute from validation rules, as explained here: http://symfony.com/doc/current/book/forms.html#field-type-options-guessing
However, I can't find a way to make Symfony 2.8.2 "guess" a <textarea> instead of an <input type="text"> :-(
My first idea was to increase the allowed length, but even with Length: max: 100000 in validation.yml, Symfony is unimpressed and just gives me <input type="text" maxlength="100000" />.
EDIT: #chalasr: I'm talking about an entity which is not mapped to the database. Sorry for not mentioning that earlier!
The FormBuilder guesses the field type by checking the type in the mapping of the corresponding property, in the entity.
Use text instead of string as type of your column mapping, and the FormBuilder will use a textarea instead of an input.
Example :
/**
* #ORM\Column(type="text")
*/
protected $field;
Output with $builder->add('field'); :
<textarea id="entity_field" name="entity[field]" required="required"></textarea>
For more info look at the Symfony\Bridge\Doctrine\Form\DoctrineOrmTypeGuesser.
Update
So, you don't use a mapped class.
Look at the FormBuilder, as you can see, if there is no corresponding Guesser found, the form type will be a TextType (input text).
Otherwise, there is 3 different Guesser:
FormTypeGuesserChain
DoctrineORMTypeGuesser
ValidatorTypeGuesser
Because your class is not mapped, Symfony will use the ValidatorTypeGuesser to guess the type of your field.
This Guesser looks for constraints in your class.
For example, if your field has a Type constraint with type integer, the NumberType will be used and an input type number will be rendered.
My first idea was to use a Length constraint with a big min-length.
But, after many tries and looks in classes, it seems the TextareaType is never guessed, unless your class is mapped and your field has text as type (DoctrineTypeGuesser is used) .
So, without a mapped class, Symfony cannot create a textarea from type guessing.
For more informations look at the ValidatorTypeGuesser::guessTypeForConstraint.
See also the Form Type Guessing chapter of documentation, it shows how create your own TypeGuesser with a good example.
This little problem has kept me up for a couple of nights now.
I have the following UIMA Ruta script:
(Action.type=="info_req"{->CREATE(CompAction,"type"=Action.type)}
Preposition? Article? ServiceItem{->FILL(CompAction,"target"=ServiceItem, "num_targets"=1),SHIFT(CompAction,1,4)}
(Preposition? Article? ServiceItem)?{
->FILL(CompAction, "target2"=ServiceItem, "num_targets"=2, "selection"="OR") })
{->SHIFT(CompAction,1,1)}
;
It is supposed to match the following sentence:
I want information about the card about the gold credit card
Annotation Action matches "I want information"
Annotation Preposition matches "about"
Annotation Article matches "the"
Annotation ServiceItem matches "card" and "gold credit card"
The desired result should be a CompAction Annotation with the following features:
Feature target: (type ServiceItem) card
Feature target2: (type ServiceItem) gold credit card
Unfortunately, the result I get is:
Feature target: (type ServiceItem) card
Feature target2: (type ServiceItem) card
i.e. I get the same ServiceItem twice, which seems to be a referencing problem, unless I am doing something very wrong.
For UIMA Ruta 2.1.0: The FILL action considers the complete rule match for the values of the features and, thus, the second FILL action also selects the first suitable annotation. A solution for this problem could be to use different types (subtypes) for the different ServiceItem annotations in order to distinguish them.
For UIMA Ruta 2.2.0: The functionality is implemented and is already available in the current trunk. The rule should do as desired.
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