** TEAM FPM ** – Input Tokenizer in FPM GUIBBs
Use
A new type of input field, the so-called ‘Input Tokenizer’, has been introduced in the GUIBBs Form@GL2.0, Form Repeater, and Search. Such a field will show a token on the UI instead of the (technical) key that is entered. You can configure the format of the token so that text, together (optionally) with the (technical) key can be displayed. Therefore, if an application wants to provide an input field on the UI that displays not just the entered key, a tokenizer field could be an appropriate alternative.
There is a specialty in the GUIBBs Form@GL2.0 and Form Repeater: Depending on the data type of the respective field, the input tokenizer may also be a ‘Multi-Tokenizer’. This allows multiple keys to be entered one after the other into the field, each of them represented by a token on the UI.
GUIBBs Form@GL2.0 & Form Repeater
Example
A user wants to enter a language (e.g. as an employee skill) by selecting an entry from the F4 help of an input tokenizer field. The F4 help displays Language and Name (supplied by a DDIC search help). In the input tokenizer field, the language name (field Name) will be displayed in addition to the language key (field Language). If the field is a multi-tokenizer field, the language selection can be done several times and multiple tokens will be displayed in the input tokenizer field, as shown in the screenshot below.
The user can also enter a language key directly (without using the F4 help). After pressing Enter, the language name (field Name) will be displayed in the input tokenizer field in addition to the language key (field Language).
Figure 1: Single- and multi-tokenizer fields in a GUIBB Form@GL2.0
Figure 2: F4 help for a tokenizer field that has a DDIC Search help
Configuration
A feeder class field of type ‘Input Tokenizer’ can be configured just like any other field in the GUIBBs Form@GL2.0 and Form Repeater. Once the display type ‘Input Tokenizer’ is selected for the field, there will be several display-type-dependent properties and actions visible in the ‘Attributes’ panel of FLUID.
Figure 3: Configuration of a tokenizer field with DDIC Search help in the GUIBB Form@GL2.0
Display-Type-Dependent Properties:
- DDIC Search Help: Name of the associated elementary DDIC search help of the field, if there is one. The property will then be shown in read-only mode. If there is no associated elementary DDIC search help, the property will not be visible.
- Collective DDIC Search Help: Name of the associated collective DDIC search help of the field, if there is one. The property will then be shown in read-only mode. If there is no associated collective DDIC search help, the property will not be visible.
- Alt. DDIC Search Help: Name of an alternative collective/ elementary DDIC search help if the associated collective/ elementary DDIC search help is not suitable. If there is no associated DDIC search help at all, the property will not be visible.
- Elementary DDIC Search Help: Name of the elementary DDIC search help that will be used for the determination of the token text. The property is only visible if there is an associated collective DDIC search help of the field.
- DDIC Search Help Text Field: Name of the field in the elementary DDIC search help that is used for the determination of the token text.
- OVS Class Name: Name of the associated OVS class of the field, if there has been one specified in the feeder method GET_DEFINITION. The property will then be shown in read-only mode.
- Token Text Format: Determines the format of a token; should it be displayed as pure text or as text together with the (technical) key (positioned before or behind the text).
- Input Help, Suggest History, Suggest Values: Same as for a field of display type ‘Input Field’.
Display-Type-Dependent Actions:
- FPM Event ID for onEnter: ID of the FPM event that is triggered when something has been entered into the input tokenizer field and Enter has been pressed (optional).
- FPM Event ID for onEdit: ID of the FPM event that is triggered when a token in the input tokenizer field is edited (optional).
- FPM Event ID for onDelete: ID of the FPM event that is triggered when a token in the input tokenizer field has been deleted (optional).
Technical Background
To enable a field to be configured as an ‘Input Tokenizer’, its data type must be one of the permitted data types for input fields. It may also be a table type of such a data type. In this case, the input tokenizer field will be treated as multi-tokenizer on the UI.
An input tokenizer field must either have fixed values or an associated or alternative collective/ elementary DDIC value help in order to enable automatic tokenization of the input field in the GUIBBs Form@GL2.0 and Form Repeater. If this is not the case, applications must enable tokenization themselves, for example, in the case of an input tokenizer field with an associated OVS class name in the feeder class. But even if automatic tokenization in the cases mentioned above is not sufficient there is the alternative possibility for applications to enable tokenization themselves. For an application-specific tokenization the application must provide a tokenizer class that implements interface IF_FPM_TOKENIZER. This class may also be the feeder class itself. The tokenizer class instance must be assigned to the feeder class field in feeder class method GET_DEFINITION by assigning it to component TOKENIZER of the field description.
Methods of interface IF_FPM_TOKENIZER:
- GET_TOKENS_FROM_INPUT: This method is called in the PAI phase at WDDOBEFOREACTION. It is intended to provide a table of tokens that are determined from the user input in an input tokenizer field. For this, the method provides the field name IV_FIELD_NAME and the user input IV_INPUT_VALUE as importing parameters (and in case of the Form Repeater also the row index IV_INDEX of the repeating unit). The exporting parameter ET_TOKEN contains the table of determined tokens.
- GET_TOKEN_FROM_KEY: This method is called in the PBO phase after feeder class method GET_DATA has been processed. It is intended to determine the token text, the token tooltip, and the token validity for a given token key. For this, the method provides the field name IV_FIELD_NAME and the token key IV_TOKEN_KEY as importing parameters (and in case of the Form Repeater also the row index IV_INDEX of the repeating unit). The exporting parameter EV_TOKEN_TEXT contains the relevant token text, EV_TOKEN_TOOLTIP the token tooltip, and EV_TOKEN_INVALID indicates whether the token key is invalid or not.
GUIBB Search
Input Tokenizers are also available in the Search GUIBB. Analogous to the GUIBBs Form@GL2.0 and Form Repeater, a search attribute for which the tokenizer feature is enabled displays not only the (technical) key that is used for the internal search, but a token. The format of the token can be configured. However, the configuration of a tokenizer field as well as the tokenization is slightly different in the GUIBBs Form@GL2.0 and Form Repeater compared with the Search GUIBB.
Example
A user completes the search statement Travel Agency by selecting the F4 help in the relevant search field. The F4 help displays Agency Number, Agency Name, City and Country (supplied by a DDIC search help). If the tokenizer feature is enabled, the field Agency Name can then be displayed in the search field in addition to the key field (Agency Number).
Figure 4: Tokenizer fields in a GUIBB Search
Configuration
You configure whether a search input field is a tokenizer field in FLUID in the Attributes panel of the Search component using the following fields. The prerequisite is that either an elementary or collective DDIC search help, an OVS class name, or a tokenizer class is assigned to the search attribute in the field description of the feeder class method GET_DEFINITION.
Figure 5: Configuration of a tokenizer field with DDIC Search help in the GUIBB Search
Value Help-Dependent Properties:
- Enable Token: Enables the search input field to be treated as tokenizer field.
- DDIC Search Help: Name of the associated elementary DDIC search help of the field, if there is one. The property will then be shown in read-only mode. If there is no associated elementary DDIC search help, the property will not be visible.
- Collective DDIC Search Help: Name of the associated collective DDIC search help of the field, if there is one. The property will then be shown in read-only mode. If there is no associated collective DDIC search help, the property will not be visible.
- Elementary DDIC Search Help: Name of the elementary DDIC search help that will be used for the determination of the token text. The property is only visible if there is an associated collective DDIC search help of the field.
- DDIC Search Help Text Field: Name of the field in the elementary DDIC search help that is used for the determination of the token text.
- OVS Class Name: Name of the associated OVS class of the field, if there has been one specified in the feeder method GET_DEFINITION. The property will then be shown in read-only mode.
- Token Text Format: Determines the format of a token; should it be displayed as pure text or as text together with the (technical) key (positioned before or behind the text).
Technical Background
If an elementary or collective DDIC search help is assigned to a search attribute an automatic tokenization is possible. Alternatively, the application can take care of tokenization itself. In the case of a search attribute with an associated OVS or a search attribute without any value help the application must take care of tokenization as well. To do this, the application must provide a tokenizer class that implements interface IF_FPM_TOKENIZER. This class may also be the feeder class itself. The tokenizer class instance must be assigned to the feeder class field in feeder class method GET_DEFINITION by assigning it to component TOKENIZER of the field description.
The use of the two methods of interface IF_FPM_TOKENIZER in the Search GUIBB is different than in the Form@GL2.0 GUIBB and the Form Repeater GUIBB. In contrast to the latter two, where interface method GET_TOKENS_FROM_INPUT is called in the PAI phase and interface method GET_TOKEN_FROM_KEY is called in the PBO phase, always the same interface method is called in the Search GUIBB for a particular search attribute in both, the PBO and the PAI phase. Which one of the two interface methods is called depends on the value of field USE_EXTERNAL_FORMAT in the exporting parameter ES_OPTIONS of the feeder method GET_DEFINITION and the existence of a conversion exit for the search attribute.
Methods of interface IF_FPM_TOKENIZER:
- GET_TOKENS_FROM_INPUT: This method is only called if the option USE_EXTERNAL_FORMAT in the feeder method GET_DEFINITION is enabled and the search attribute has a conversion exit (for example data element SPRAS with conversion exit ISOLA). In this case, the method provides the search attribute name IV_FIELD_NAME and the external format of the search attribute value IV_INPUT_VALUE as importing parameters. The exporting parameter ET_TOKEN contains the table of determined tokens. The Search GUIBB, however, supports just one token and does not use the field TOOLTIP in this table currently.
- GET_TOKEN_FROM_KEY: This method is usually used for tokenization in the Search GUIBB. It is called for all search attributes if the option USE_EXTERNAL_FORMAT in the feeder method GET_DEFINITION is not enabled. In the case that the option USE_EXTERNAL_FORMAT is enabled this method is called only for those search attributes that do not have a conversion exit. The method provides the search attribute name IV_FIELD_NAME and the internal format of the token key IV_TOKEN_KEY as importing parameters. The exporting parameter EV_TOKEN_TEXT contains the relevant token text and EV_TOKEN_INVALID indicates whether the token key is invalid or not. The token tooltip EV_TOKEN_TOOLTIP is currently not used in the Search GUIBB.
Test application
- WD application configuration: FPM_TEST_TOKENIZER
- Form@GL2.0 component configurations: FPM_FORM_GL2_TEST_TOKENIZER, FPM_FORM_GL2_TEST_TOKENIZER_EVT
- Form Repeater configurations: FPM_FORM_REP_TEST_TOKENIZER, FPM_FORM_REP_TEST_TOKENIZER_EVT
- Search configuration: FPM_TEST_SEARCH_E_ANA_TOK_CC
- Feeder class for Form@GL2.0 & Form Repeater: CL_FPM_TEST_TOKENIZER
- Tokenizer class for Form@GL2.0 & Form Repeater: CL_FPM_TEST_TOKENIZER
- Feeder class for Search: CL_FPM_TEST_SEARCH_E_ANA_TOK
- Tokenizer class for Search: CL_FPM_TEST_SEARCH_E_ANA_TOK
Hi Expert
I found out that if I entered some lowercase character in a search field of a SEARCH GUIBB,The search content is always been converted to uppercase. I am looking for a solution for my case, are you aware of how to solve the issue?
Hi Xie,
It depends on the flag LOWERCASE in the domain of the used data element of a search attribute. If this flag is checked then the characters are not converted to uppercase and they are passed case sensitive to the application.