SAPUI5 smart controls are a special category of controls that help to boost application development and are part of the SAP Fiori Elements offering. Specific feature of the smart controls is that they can interpret the OData protocol and be adaptive depending on the protocol's annotations. For instance, the smart field can morph into a simple input, date picker, checkbox and other types. In addition, annotations can control the visibility, edit or read-only mode and other things for which usually you’ll need to code it in the business logic. Smart controls can be used in freestyle applications, i.e. without SAP Fiori Elements framework. However, the recommendation is that you first evaluate the existing offering from SAP Fiori Elements to get the lowest TCD for your application based on SAP Fiori .
Smart controls evolve constantly, thus I'm going to layout some highlights of the latest developments.
Smart Table
Message handling
We’ve introduced the possibility to have a message strip above the table to indicate that there are errors (or other messages) inside the table. This helps the user to quickly realize if there are problems or other things requiring his or her attention. Sample can be found
here.
Column size handling
In the smart table, in combination with the grid table, we already had column size computation. We introduced a new algorithm to have a better calculation that takes into account service metadata and column header. There is now an annotation (
CSSDefaults) that can be used to define the column width. In addition, we introduced this behavior for the responsive table and reworked the algorithm for the grid table. End users can also resize the columns as they like and this is stored in the variant management. Try out this
sample. Stay tuned for more documentation in the future.
There is now an option to show and hide columns depending on their
importance annotation. If there is not enough screen space, columns can be placed in the pop-in area. Try out this
sample.
Smart Field
Recently used values history
This is a convenient feature much like browser's input autocomplete. It helps the user to quickly select a previously used value in a field. Fields holding personal sensitive data can be annotated, so no data is stored. Bear in mind that this feature works only in Fiori Launchpad context as it uses FLP Personalization service for persistence. It is enabled by a parameter in the FLP. More about this can be found in this
article.
ID and description in edit mode
Some time ago, we introduced the possibility to show ID and description for the fields in read-only modes using the
TextArrangement annotation. Now, in combination with this annotation, we made it possible to have a description and ID in edit mode using
textInEditModeSource property. It points to the source from where descriptions are fetched for the corresponding IDs. It has three modes -
Navigation, ValueList and
ValueListNoValidation. The latter mode is suitable for scenarios where you also want to enter new values that are not included in the value list but not necessarily invalid, like the draft state.
ValueListNoValidation is now the default for the Fiori Elements applications. This property supports only strings and GUIDs. For more info check out the
API and this
sample.
Value list
In edit mode, we also added the capability to support compound (or composite) keys. This means if an entity type defines more than one key, then we use all of them when sending the backend query to fetch the description. Before, we were using only the first defined key and that sometimes resulted in more than one entry returning from the backend, so the description of the ID was not always correct. A sample can be seen
here.
For smart field and smart filter bar we added support for the
ValueListParameterConstant that provides an additional filtering capability (to In and Out parameters) for value lists in value help and typeAhead functionality. By nature, this parameter and is not shown anywhere. More info can be seen in the
API and
sample.
If smart field is rendered as sap.m.Combobox it will now handle values that are not part of the value list differently. Before, handling was left to the sap.m.Combobox native behavior, that was to show an error. This led to the problem that we're sending NULL to the backend instead of what user has typed. This was perceived as bad user experience. Now we accept the value, even it's not existing in the value list and send it to the backend. A sample can be found
here.
Suggestion highlighting
For smart field and smart filter bar, we've improved the highlighting of the suggestions. When the user starts typing, the beginning of each word that matches in the suggestion table will be displayed in bold letters. And this now is consistent with controls like sap.m.Combobox. Try out this
sample.
Currency handling
We added support for variable-scale annotation that allows multi-currency fields to change the scale according to the selected currency. In contrast to OData V4, that was not possible for standard OData V2 setup.
Smart form
ID and Description in edit mode
It is now possible to propagate the ID and description arrangement in edit mode on a smart form level valid for all smart fields contained in the form by adding custom data. For example:
<form:customData>
<core:CustomData key="defaultTextInEditModeSource" value="ValueList"/>
</form:customData>
In case some of the smart fields in the form need to have other setting for
textInEditModeSource they can override it locally.
UI.Importance annotation
There are situations where the screen can be rather small and in that case the application should show only the most important data for the user. To assist this scenario, the smart field respects
UI.Importance annotation and in combination with the Smart form
importance property, it will show the fields respecting their
importance type. Sample can be seen
here.
Semantically related fields
You can now define fields in one row that belong together. This can be achieved by using the
SemanticGroupElement control
. You can add up to three fields that in edit mode would render as separate inputs with delimiter that is inherited from the form, but in read-only mode fields would render closer together visually appearing as pieces belonging together. This feature is still in experimental state.
Value help dialog
Based on user testing we did some optimizations in the interaction and visuals of the value help dialog. More about that can be seen in this
article. Keep in mind that this is work in progress so there will be more changes made with future releases. In case you have tests that rely on specific control structure in the dialog, then they might need some adjustments.
Smart chart
To display dates in a standardized format, calendar and fiscal OData V4 annotations are now supported with the use of activateTimeSeries property. For more information, see the
API Reference for the annotations and the
Samples.
Conclusion
Keep an eye on the SAPUI5 roadmap as Smart controls continue to evolve and improve. They are essential part of the SAPUI5 offering and exist to make developers' lives easier. Used in combination with SAP Fiori Elements this drastically reduces the required application code.
Please, let me know in the comments section if you find such articles providing noteworthy highlights useful. Additionally, you can share what else you might want to see in direction of smart controls. All feedback is welcome.
For more information on UI5:
