053: Recycling-Heroes - Multi-Input Field (Document)

In today's episode, we'll continue working on our document app and implement additional features and convenience functions. This will allow users to later operate the app, upload more documents, and manage various tags on a document, which should be relatively easy.

Readonly

Last time, it was still possible to configure the document ID when creating a document. We no longer need this, as the ID is automatically generated as a UUID, and the system handles its management. Therefore, we remove the property from the behavior definition and add the suffix to the top of the actual field so that the field remains read-only at all times and we cannot make any changes. In our test case, we now create a new document, assign it a description, a long text, and a type, and then attach a dummy document to validate the creation process. The process for new documents now works, and we can move on to the next annotations.

Annotations

To do this, we define an annotation on the Description field in the Metadata Extension. Here, we activate the multi-line text. This allows for the input of longer text, as a larger input field is generated in the UI. Setting this to True activates the new control. In the second step, we define the actual association with the tags. We need these to generate the multi-input field. Next, we define an annotation for the identification; that is, the field then appears on the object page. Besides the position and the assignment to the facet, we define the value to be output. We do this via association and select the tag ID field. Let's test the output in the UI and go into edit mode. The input for the description is now displayed as long text. The tag field is there and ready for input, but we cannot yet select any values here.

Document types

Therefore, as a first step, we need to build new value helpers for the existing objects in order to then integrate them into our UI. Let's start with a value help for the document type. In this case, we ultimately selected the wrong template, or rather, the default was set, and an old view was generated. We don't necessarily have to delete this as an object; we can simply choose a new template. To do this, we remove the entire code content and can then use the system's Content Assist (Ctrl + Spacebar) to access the various templates we can insert. Here, we select the View Entity to insert the template for that View Entity. We adopt the name of the Core Data Service as well as the entity we are reading from, and clean up the header by removing some annotations that we don't need in this view. Next, we take all fields from the underlying Core Data Service to get an initial suggestion and activate the search via the "searchable" annotation in the Core Data Service. Then, we define the various elements as searchable and use the Fuzziness Threshold to set how the fuzzy search affects each field. This allows a search field to search both fields: the document type and the description. We also define the text element for the document type so that we see not only the technical code but also the text.

Tags

In the next step, we create the value help for the various tags. To do this, we define a new service directly above the defined Core Data Service for the tags. To make editing easier for you, we place both value helps side by side, allowing you to copy the various annotations for a faster editing flow. We copy the search function as well as the various fields that appear in the search, and only adjust individual elements where necessary. Then we activate the Core Data Service, and this value help is also complete.

Value Helps

We can now copy the new value helps into our documents and insert them as annotations at the Core Data Service level. Therefore, we don't need to remap the elements, as they are already correctly defined. The document type is located at the top level of the root document entity; that's where we insert it. We then copy the tag value help to the level below, namely the child document tag entity. Even though the element is displayed at the top level, the field and the value help still originate from the level below.

Let's now test the value help in the UI. This is now rendered behind the field. For the document type, we see all existing document types in the system and can select one. For the tags, we can now activate multiple tags. Here, the UUID is inserted into the element. Generally, multiple entries are possible via the multi-input field. Currently, we have a problem where the correct text isn't being displayed; for example, we only see the UUID in the field, which doesn't provide any real added value. Therefore, we'll cancel the saving process and adjust the information in our Core Data Services.

Adjustments

To do this, we'll make an adjustment to the value help for the document type. Here, we want to have a dropdown menu instead of the value help, which we've already done in previous episodes. We'll use the "ObjectModel" annotation and set the "Size Category" to XS, which will then generate a dropdown list in the UI. Next, we'll address the missing text in the UI. Therefore, we'll navigate to the lowest level of our RAP object for the tags and add the association to the value help. We can also use the value help to determine the text required for a particular tag. Once we've included the Core Data Service via association, we can switch back to the Consumption View and include the Description field there. This places it within the entity but prevents it from being saved in the Draft, which isn't necessary. Next, we can insert the text arrangement and define that we only want to see the text. This hides the UUID, and we then define the text element that we created locally. This way, we ultimately display the various tags as text. Let's now test all the changes in the UI. First, change the document type to an image from a car, adjust the title, and then select appropriate tags for our document. Even during the selection process, we see that the lower section no longer displays the UUIDs, but instead loads the text directly, making it clearer. The text is still displayed when saving the entity; the dot between the two indicates that we have two entries within the field.

We can now make the same adjustments for the document types by adding the corresponding entry for a document type at the root level and then including the text for that document type in the Consumption View. We then add further properties, such as specifying that the text should be displayed first, followed by the technical value, and then bind the text to the actual document type. Since these are identical steps to the previous one, we won't show them in this video, but we will at least look at the final result in the UI. The record now displays the actual text in the document type, followed by the technical value, which is stored in the database. In a production UI, the technical values are usually not of interest to the business department. Only the actual text should be stored here.

Summary

Today's episode focused primarily on how to enable a multi-input field in our entity to store multiple values in one field, even though this information comes from a child entity. In addition, we used various annotations to provide value aids and create a long text field for our text. This makes the app look much more user-friendly and allows us to focus primarily on the topic of data next time. So, thanks for watching and see you next time!

YouTube
Video