In my role as development architect for SAP Fiori elements I have many opinions about right and wrong development practices. Working with customers, partners, and SAP S/4HANA colleagues, I come across many custom extensions. Some are great examples of elegant design that validate the need for and power of the flexible programming model provided by SAP Fiori elements for OData v4. Others are implemented using poor programming practices such as accessing internal controls or methods, or ignoring features provided by SAP Fiori elements. Those are risky as there’s a chance your application will break after an upgrade. In this post, I will share several examples of bad coding practices, explain why they are wrong, and show you the right way to implement these features instead.
Hide Edit Button
You want the whole app or a certain object to be read-only.
Wrong way:
Access the edit button provided by SAP Fiori elements by ID and hide the button.
This is not a good idea because of the following reasons:
- Accessing the edit button provided by SAP Fiori elements is not allowed and might break in the future.
- SAP Fiori elements also provides the preferred-mode=edit feature that creates a draft directly when entering the page
- If you want the application or the object to be read-only you should set it on a service level
Correct way:
Use the OperationAvailable annotation on the Edit action. By using this approach there’s no need for a custom extension and thus also no risk of breaking your app.
Example of hiding the edit button by setting the OperationAvailable statically to false
Access Action Buttons via ID to Set Visible and Enabled
You want actions to be disabled or hidden for certain objects.
Wrong way:
Access the action buttons provided by SAP Fiori elements by ID and hide or disable the buttons.
This has similar issues to hiding the edit button. SAP Fiori elements does not allow you to access the action buttons and your app might break. Also, your service should expose the correct state of actions.
Correct way:
Instead, you can enable and disable actions via OperationAvailable or show/hide the actions via UI.Hidden annotations as described in the SAPUI5 documentation. For the standard create and delete action you can use CreateHidden/DeleteHidden. And for their enablement with Capabilities.NavigationRestrictions, InsertRestrictions and DeleteRestrictions as described in the documentation for adding actions to table.
If the enablement or visibility is dynamic, you can annotate a path to a control property. You can use SideEffects annotations to update the control properties.
Or you can even add some expressions (supported by CAP, in RAP you need to add local annotations).
By using this approach there is no need to add any extension.
If your logic to enable/disable or show/hide needs custom coding running in the client, you can define formatters in the manifest.
Example of an action only enabled if the property “isVerified” is true
Hide Sections Dynamically
You want to show and hide sections on the object page dependent on the shown object type.
Wrong way:
You implement a hook that checks the currently shown object and accesses the sections on the screen by ID and show/hide them.
This is risky as SAP Fiori elements does not support access and operate on object page sections. And whenever business logic changes you need to adapt this coding.
Correct way:
Use the UI.hidden annotation and use SideEffects annotations to control and update the visibility of sections. By doing this there is no need for any custom extension. And you have the logic to show or hide sections at the service level. Whenever business logic needs a change, you can easily adapt it on the service without any need to touch your UI project. Same as for actions, where you can use a path to control the visibility or use annotation expressions. You'll find further documentation about adapting sections on an object page.
Example of showing a section only if the “Delivered” property is set to true
Access Internal Table and Change Threshold
You want to change the default threshold (= the amount of data read once the table is visible or the user scrolls down) provided by SAP Fiori elements.
Wrong way:
You access the internal table by ID and change the threshold.
This approach is not supported by SAP Fiori elements and might break in the future.
Correct way:
Annotate a presentation variant and define the MaxItems annotation.
With this annotation there is no need to implement a custom extension at all and there’s no risk your application breaks after an upgrade.
Example of a PresentationVariant defining a threshold of 30
Access MDC Table and Change the Selection Mode
You added a custom action, and you want to change the selection mode of the table to allow single selection only.
Wrong way:
You access the internal table by ID and change the selection mode.
This approach is not supported by SAP Fiori elements and might break in the future. Also, this interferes with the logic provided by SAP Fiori elements to set the selection mode. For example, if your entity set is deletable, a delete button is added by SAP Fiori elements, and users expect to be able to select and delete more instances at once.
Correct way:
Change the selection mode in your application’s manifest. The SAP Fiori Tools - Application Modeler provides you with an effortless way to change the selection mode.
By using this feature, you do not need to implement a custom extension, thus also no risk an upgrade breaks your application. And you achieve a consistent UX.
Changing the selection mode with SAP Fiori Tools
Conclusion
SAP Fiori elements already provides many features out of the box, so you do not need to implement any custom extension. Check out our documentation, the feature map and the FPM Explorer to learn about features provided by SAP Fiori elements.
And if there is a need to implement a custom extension, SAP Fiori elements provides an extensionAPI that allows you to implement upgrade-safe custom extensions.
Please use the comments to let me know if you want me to provide a second blog with more examples.
- SAP Managed Tags:
2 Comments
