(Natural language) period-to-dates conversion
Designer 7.9 and Collections 1.15 introduce a new Period field type and accompanying Period index type which allows users to enter and save date periods expressed in natural language, like "12th century", "Spring 2022", "late 2018", "Early 19th Century - 2022", "1950s" etc., in a record while the indexed values actually become date ranges in the form of real (numerical forms of) ISO start and end dates, like 1100.0101 - 1199.1231, 2022.0301 - 2022.0531, 2018.0901 - 2018.1231, 1800.0101 - 2022.1231 and 1950.0101 - 1959.1231 respectively: the user will never see these ISO dates as the entered natural language date period will be saved in the record However, when the user searches this field, he or she can only search it on complete natural language periods, like "12th century" (and years in digits), not on single words (not even truncated) from the natural language period like "century" nor on ISO dates which include months and/or days. So the search language parser converts the search key to an ISO date range too. If the user searches on a broad period, the search will not only yield that exact period but also narrower periods within that broader period. One can currently only search on a single date period, not on date period ranges. A full overview of all English natural language period elements that can be entered in a Period field (or when searching the index on this field) can be found here. Grammar files for parsing the natural language date periods into ISO dates are currently included in Collections in English (en-GB), Dutch, Danish, Welsh (cy-GB), Portuguese and Swedish. Parsing of date entry in this field depends on the current user-interface language in Collections, so while working in the Dutch UI language you'll have to enter date periods Dutch and while in English you should enter date periods in English. The same applies to searching, so in Dutch a user would search for e.g. my_period_field from "21e eeuw", while in English you search for my_period_field from "21th century", but in both scenarios you would find the same records because the index is language independent.
Validation takes place after changing and leaving the field. If the user enters a period that isn't recognized by the parser, a warning will be shown similar to the one below (although field name and field tag can be different) and the user will have to enter a different period.
Setup is quite easy:
| 1. | Create a new database field in the desired .inf, of Data type Period and length 100, for example: Note that Period fields cannot be multilingual as well! |
| 2. | Then create a Period index for it and reindex it, for example: |
| 3. | And finally create a screen field for the new field on the desired screen. This can just be a Text field. For example: |
| 4. | Since the grammar of a language can be region specific you may want to configure what the region of some or all used UI languages is. A good example is the English language which has different date parsing rules for Great Britain (en-GB) and Unites States (en-US). The interface languages that must be available in your Collections installation are specified in the <Setting Key="Languages" Value="..." /> setting underneath the relevant <SessionManager> node in the settings.xml for Collections. It is not mandatory to specify a region behind a language, but it can't hurt to be specific from the start. So use e.g. <Setting Key="Languages" Value="en-GB,nl-NL" /> instead of <Setting Key="Languages" Value="en,nl" />. |
| 5. | Recycle your Collections application pool and you can test the new field. |
The record XML will hold the natural language period and the so-called culture (UI language plus region code) in which the value was entered and successfully parsed, for example:
<field tag="WL" occ="1" culture="nl-NL">13e april 2001</field>
In the SQL database the new table type will look something like the following:
(The language column is currently not in use. Its presence is for possible future use.)
Note that implementing this new field type will break compatibility with older versions of Designer and Collections, but removing the new field, index and screen field should restore that compatibility although the obsolete index table will remain present in the SQL database. Remember to also update your other Axiell software to their latest version, after implementing this new functionality.
Feedback
