Script: Recycling-Heroes - UI Design Contact [011]

Table of contents

• Introduction
• Metadata Extension
• Selection
• List
• Header
• Content
• Test
• Overview

Introduction

In the last video, we created the RAP object step by step. However, we currently lack a consistent UI for our application. Therefore, in this video, we will look at the design and structure section by section.

 

Metadata Extension

In the first step, let's start by creating the Metadata Extension. This is a separate object where we can outsource our various UI annotations to keep the actual view clean and thus maintain an overview. We basically create the UI annotation at the consumption view level. Here, we use the same name as the actual Core Data Service. This makes it easier to assign objects later. The "Layer" annotation isn't particularly useful so far, so we'll add "Customer" as layer here.

Using Content Assist or CTRL + SPACE, we get a selection of possible fields, or, as in our case, we can insert all elements directly. To be able to go through the various points of the UI step by step, we'll first hide all elements. We can use the UI.hidden annotation for this. To adjust all elements, we'll go through the view again with Find and Replace to hide the warning messages. We can format the elements in the view using the Pretty Printer. Finally, we update the UI and look at the initial state.

 

Selection

Let's start by building the List Report, the entry page of the most frequently used template. Similar to the selection screen of a report, we first define a few fields that the user can use to filter by default. With the UI.selectionField element, we define the fields for which we want to display the filters. With Position, we define the order of the fields from left to right. To do this, we display the contact ID, the contact type, and the country as filters. If we then reload the UI, the three fields will be displayed in the upper part, and we can now filter the data.

 

List

Now we want to see the first entries in the list. We can display the elements in the list using the UI.lineItem annotation. Here, we again specify a position to determine the order of the elements on the screen. The list is always the first part of the data the user sees after executing the filter. This should contain essential information that the user can use to make initial decisions. We will also display the contact ID, contact type, first name, last name, city, and country. If we then reload the application and execute the selection with GO, the data will now be displayed in the list.

We'll add some text above the table. We can add a description of the data using UI.headerInfo.typeName. There are two variants here, depending on how much data is loaded. The text in the application can then be translated later. If we now reload the application, the text will now be displayed in the table header. If we reload the data once, the total number of all records in the database for this selection will be displayed. This way, we know how many records we're working with.

By clicking on a record, we switch to the object page, which is the details page where we normally find all the application details. Since not all information can always be displayed in the list report, we can include all details and sub-entities in this list. Currently, the page is still completely empty, except for the Edit and Delete actions.

 

Header

To do this, let's first create the header with a heading and text below it. For this, we again find a title and a description under UI.headerInfo. Using Value, we can directly take a field from the entity, the content of which will then be displayed in the UI. If we go back to the Fiori UI and refresh, both pieces of information will be displayed.

Now we want to display the first group of data in the header. The header is normally not editable; here you will only find information, which should provide an important overview. To do this, we define a facet, which is a part of the UI. We can create various facets here, starting with the first object. A facet always requires a unique ID, which you can name freely. We usually use the "id" suffix at the beginning. A facet also has a position, which determines the order in which it is displayed, just like with fields and the list. We use FIELDGROUP_REFERENCE as the type, which assigns elements from the Fieldgroup area. Using Purpose, we can define that the facet is displayed in the header. We use the label to give the group a heading, and we can use the targetQualifier to assign elements from the field list to the group.

Since we're using a field group, we'll also define the element for our field. In addition to the position, we also use the qualifier, which we use to assign the field to a facet if we have multiple facets. If we now reload the UI, the group with the title will be displayed, and the two users or fields with their content will be displayed below it.

 

Content

Now we define the actual content that we want to display and maintain on the page. To do this, we create a new facet, this time of type IDENTIFICATION_REFERENCE. We don't need to define the purpose here, as the default value is STANDARD and is therefore displayed in the main area. We define a label and a target qualifier again so that we can assign fields right away. To assign fields to the reference, we need to use the UI.identification annotation. As with the field group, we define the element at the field, set a position, and a qualifier to assign the element to the section. In this case, we do this for two fields. If we then go back to the UI, the new section will be loaded, and the two fields will be displayed.

Now let's create a new section for the remaining contact details. In this case, we define a collection. This is a combination of several facets under a common point. The collection thus receives an ID, a position, and the type COLLECTION. We also assign a label, which will later be displayed as a navigation tab. We now assign two more facets to the collection: one for the person's data and one for the address. To connect the facet to the collection, we must define the parentId element and specify the collection ID as a reference. In this case, we define two field groups to map the remaining fields. We now assign the fields to the different field groups accordingly. We assign the first name, last name, and birthday to the person. Street, house number, city, postal code, and country according to the address. In the UI, we now see the details and, within the details, the two groups. Since we want to see the person in front and the address behind, we still need to adjust the positions of the two groups. After updating, the person is now at the front, followed by the address.

Finally, we create one last facet for the digital contact, i.e., phone and email. It doesn't matter whether you use field groups or identifiers for your UI. With both, you can map the groups and assign different elements. The only difference here is the annotation you use in development, which may also allow you to separate content. Let's load the UI again and see no group. What could be the problem here? Let's look at the qualifier; the same problem could exist here as with the ContactType: the actual ID is already assigned. In such cases, you can always try adjusting the IDs and qualifiers and see if the desired effect occurs. The last group should now also be displayed in the UI.

 

Test

We can now access the app's edit mode using the Edit button. Here, all fields are suggested for change. We can discard the current draft using Discard if we don't want to change the data. If we go back to the list report, we can load the data. If we set a filter, only the one entry will be loaded. Let's create a new entry using Create. We can basically fill in the various fields, and the data record is created by clicking Save. However, we are currently missing the key; this field is not ready for input and remains empty. Since the data record is not yet correct, we will delete it from our table.

 

Overview

We have now built our first RAP application that can manage the data accordingly and whose UI allows us to display and edit the data. We have defined a large number of objects in the system, and each individual layer is required for different functions. From the database, through the Core Data Services, to the final service. We also have the behavior definition to control the object's behavior. Finally, we built our UI piece by piece in the Metadata Extension. In the next episode, we'll make a few more changes to prepare the applications for the end user.

Thanks for watching and see you next time.

 

YouTube:
Video