Script: Recycling-Heroes - Value Helps and Texts (Contact) [012]

Table of contents

• Introduction
• Data Element
• Value help
• Associations
• Texts
• Search
• Summary

Introduction

In this episode, we'll create search helps for our UI, replace some technical values with text, and implement a general search in the application.

 

Data Element

In the first example, we create a search for our data element "Contact Type," where all values are contained in the domain's fixed values. Let's take a look at the domain and compare the different values. Next, we need a new Core Data Service to display the data for us in the appropriate format. The VH at the end of the view indicates a Value Help, a common abbreviation when creating the object. We'll leave the reference object empty, as we want to use a template right away. Before generating, make sure you're using the ViewEntity template.

In this example, we won't access the Code Snippet page, but will use a new IDE action that's currently still in beta. Using "Generate Code Snippet," we select the "Value Help from data element" action and specify a name for the field and the corresponding data element. After executing the action, we'll receive a suggested code, which we'll accept. Finally, we clean up the view and activate the object in the system. Now we run the data preview on the view and hold the view's result next to the domain. The fixed values and the corresponding texts are displayed.

Now we want to implement the search help in our Core Data Service at the consumption level. In front of the "ContactTypeInt" field, we execute our IDE action again and select "Define Value Help at field" in this step. Here we can enter the Core Data Service for the value help, as well as the field name. After confirmation, the template is adopted. If you know the annotation right away, you don't need the code snippet. Now we reload the UI. If we now call the field's value help, the three types are displayed. If we select a type, it will be adopted, and we can filter the data accordingly.

Now let's adjust the value help again. We actually want a dropdown menu in the UI for the three values. To do this, we need to add an annotation at the header level. Among the code snippets, we find the "Activate Dropdown" action, which inserts an annotation into the view. This defines the result set as very small, which causes the field to be converted into a dropdown menu in the UI. If we now update the UI, we get the defined dropdown menu. Here we can select the entries directly.

 

Value help

Let's now define additional value helps in the system. In the first step, we define a new value help for the "ContactId". To do this, we use the base view of the data model as a basis. Using the context menu, we can create a new Core Data Service, give it a name, and add a description. Finally, remember to define the correct template for the view. Once the new view has been created, we delete some annotations we no longer need. Then we define the fields we need in the view. In the first step, we create a new compound field. To do this, we combine the first name and last name. We then define the value help for the type, as well as in the consumption view, and remove fields that we don't need in the search help. If we then run the view, we get a preview of the data. Finally, we transfer the search to the consumption view. We now use a standard view in the system to have search help for the countries. With I_CountryVH, we should get a suitable search help.

If we now run our application, the value helps are loaded for the fields. If we call the help for the contacts, we see our defined fields in the list. For each field, there is a restriction option or a filter in the upper section. If we open the countries, we also receive the defined search help.

In the next step, we also need to expose the search help in the service as an entity. To do this, we add the various views to the service definition. If you are unable to open a search help or it is unavailable, it may be that the view has not been released.

As a final step, we correct the field in the search help. We made an error here through copy and paste, which is displayed as a warning in the IDE. Then save and activate again.

 

Associations

Before we can show the text on the UI, we first need to define the associations to obtain the necessary additional data. Therefore, we add the new views at the root level. To do this, we define an association and use the new cardinality. This replaces the old cardinality with the numbers and should also be used as the successor. We define a 1:1 access and give the entity an alias with an underscore; this is part of the best practices. Then we define the connection using the ContactType. As a final step, we need to publish the association in the view by inserting it in the lower part. We now repeat this process for the contact and the country.

Now we need a value help for the user, as well as a way to easily connect the texts. To do this, we define a new view in the SHARE package. We want to share this later, but for now we only need it for the contacts. We use the user ID, the full name, and the user's email address. Finally, we clean up the view again, run the Pretty Printer, and activate the object.

Finally, we can include the view for the creator and the last changer. We'll use two different aliases, as this could involve different information. Once we're done, we declare the two associations in the field list. As a final step, we add the associations at the consumption level and activate the object. This completes the preparatory work.

 

Texts

Now we define the texts in the view. To do this, we can use the association alias and access the field from the view. We'll therefore create fields for the ContactType description, assign an alias, and then define text fields in the view for the CountryName, CreatedUser, and ChangeUser fields.

Then we link the texts to the respective keys. To do this, we need the annotation from the "ObjectModel" area and define the newly integrated text field there. Using the "textArrangement" UI annotation, we can define how and where the text is displayed. For the type and country, the text comes first, followed by the value in parentheses. For the users, we only want to see the text; the corresponding IDs are irrelevant.

If we now go back to the UI and refresh the application, we will find the corresponding texts. For example, the type is now filled with the appropriate text and ID. The filter at this level continues to work and now also contains the text. Previously, only the technical value was displayed as the filter value. If we now switch to the application's object page, we only see the name in the user details and no longer the user ID. In the data, you will now find the corresponding country with the key in parentheses. This means we have added text to some of the technical values.

 

Search

In the last step of this episode, we want to enable a general search in the app for some fields. To do this, we first need to enable the search in the Consumption View. Therefore, we add the annotation "Search.searchable" to the header and set it to True, which activates the search field in the UI. In the next step, we need to define the standard search elements, i.e., which fields of the view will be used to search. We define the search based on the ID, first name, last name, street, and city. The fuziness determines how precisely the text is searched. With 1.0, the value is expected exactly the same and without errors; with 0.8, we don't have to enter all the letters to get a result. In principle, we can enter a value from 0.6 to 1.0.

Finally, let's test the search in the application. For example, if we enter the first name and forget the last few letters, the search will still find the rows. If we enter an ID incorrectly, we won't get any hits; however, if it is complete, then the filter is exact. Finally, if we enter the city and forget a letter in between, we'll get hits here as well. Of course, the search also works combined with the standard elements of the other filters.

 

Summary

This brings us to the end of the episode. We've integrated the various search aids into our application, added additional data via associations, and supplemented some of the technical values with text. Finally, the general search has been integrated into the application.

Next time, we'll add more information via virtual fields and further finalize the UI. Until then, thanks for watching, and see you next time.

 

YouTube
Video