OpenUI5 Documentation Update 29.08.2021

SAP · Aug 29, 2021 · ba8c650 · ba8c650
1 parent 8388219
commit ba8c650
Show file tree

Hide file tree

Showing 15 changed files with 1,068 additions and 63 deletions.
diff --git a/docs/0index.md b/docs/0index.md
@@ -104,25 +104,24 @@ OpenUI5 Version for the OpenUI5 Demo Kit
             -   [Step 16: Dialogs and Fragments](Step_16_Dialogs_and_Fragments_4da7298.md)
             -   [Step 17: Fragment Callbacks](Step_17_Fragment_Callbacks_354f98e.md)
             -   [Step 18: Icons](Step_18_Icons_776f735.md)
-            -   [Step 19: Reuse Dialogs](Step_19_Reuse_Dialogs_1945396.md)
             -   [Step 20: Aggregation Binding](Step_20_Aggregation_Binding_bf71375.md)
             -   [Step 21: Data Types](Step_21_Data_Types_dfe0465.md)
             -   [Step 22: Expression Binding](Step_22_Expression_Binding_c98d573.md)
             -   [Step 23: Custom Formatters](Step_23_Custom_Formatters_0f8626e.md)
             -   [Step 24: Filtering](Step_24_Filtering_5295470.md)
             -   [Step 25: Sorting and Grouping](Step_25_Sorting_and_Grouping_c4b2a32.md)
             -   [Step 26: Remote OData Service](Step_26_Remote_OData_Service_4406244.md)
-            -   [Step 27: Mock Server Configuration](Step_27_Mock_Server_Configuration_bae9d90.md)
+            -   [Step 26: Mock Server Configuration](Step_26_Mock_Server_Configuration_bae9d90.md)
             -   [Step 28: Unit Test with QUnit](Step_28_Unit_Test_with_QUnit_e1ce1de.md)
             -   [Step 29: Integration Test with OPA](Step_29_Integration_Test_with_OPA_9bf4dce.md)
             -   [Step 30: Debugging Tools](Step_30_Debugging_Tools_1ff250c.md)
-            -   [Step 31: Routing and Navigation](Step_31_Routing_and_Navigation_e5200ee.md)
+            -   [Step 30: Routing and Navigation](Step_30_Routing_and_Navigation_e5200ee.md)
             -   [Step 32: Routing with Parameters](Step_32_Routing_with_Parameters_2366345.md)
             -   [Step 33: Routing Back and History](Step_33_Routing_Back_and_History_8ef57cf.md)
             -   [Step 34: Custom Controls](Step_34_Custom_Controls_d12d2ee.md)
             -   [Step 35: Responsiveness](Step_35_Responsiveness_a96e18b.md)
-            -   [Step 36: Device Adaptation](Step_36_Device_Adaptation_d63a15e.md)
-            -   [Step 37: Content Density](Step_37_Content_Density_d935dbf.md)
+            -   [Step 35: Device Adaptation](Step_35_Device_Adaptation_d63a15e.md)
+            -   [Step 36: Content Density](Step_36_Content_Density_d935dbf.md)
             -   [Step 38: Accessibility](Step_38_Accessibility_ff7cab1.md)
         -   [Troubleshooting](Troubleshooting_5661952.md)
             -   [Step 1: Browser Developer Tools](Step_1_Browser_Developer_Tools_eadd60a.md)

diff --git a/...scriptor_for_Applications,_Components,_and_Libraries_(manifest.json)_be0cf40.md b/...scriptor_for_Applications,_Components,_and_Libraries_(manifest.json)_be0cf40.md
@@ -1598,7 +1598,19 @@ Description
 </td>
 <td>
 
-Relative URLs in the component, taking `embeddedBy` into account if filled, pointing to `js` \(JavaScript\) and `css` resources that are needed by the app for specifying the mandatory `uri` and an `id` \(optional\) for CSS. The JavaScript files are loaded by the `require` mechanism. The CSS files are added to the head of the HTML page as a link tag. The resources are resolved relative to the location of the `manifest.json` file.
+Specifies additional `css` and `js` resources of the Component.
+
+CSS files are added to the head of the HTML page as a link tag. JavaScript files are loaded by the `require` mechanism.
+
+Two settings can be defined per resource:
+
+-   `uri` \(mandatory\): URLs are resolved relative to the Component, taking the `embeddedBy` setting into account \(if filled\).
+
+-   `id` \(optional\): Only for `css` resources; the id for a CSS file's `<link>` element.
+
+
+> ### Note:  
+> The usage of `js` resources is deprecated. Please use regular `dependencies` instead.
 
 
 

diff --git a/docs/Extension_for_Data_Aggregation_7d91431.md b/docs/Extension_for_Data_Aggregation_7d91431.md
@@ -25,6 +25,8 @@ The following client-side instance annotations can be used to access a node leve
 -   `@$ui5.node.level` – A non-negative integer which describes the node level; "0" is the single root node which corresponds to the grand total row, "1" are the top-level group nodes, etc.
 
 -   `@$ui5.node.isExpanded` – A boolean which determines whether this node is currently expanded. `true` means yes, `false` means no, `undefined` means that \(the state is undefined because\) this node is a leaf. As an implementation detail, the annotation might simply be missing for leaves.
+-   `@$ui5.node.grouplevelCount` – An integer value which determines the count of the direct children of a group node. As an implementation detail, the annotation is only available if the corresponding node is expanded.
+
 
 Two scenarios are supported:
 

diff --git a/docs/JavaScript_Code_Issues_030fcd1.md b/docs/JavaScript_Code_Issues_030fcd1.md
@@ -20,7 +20,7 @@ This section lists some of the most important issues that should be avoided when
 
 Don't use or override "private" methods or properties. Private functions are typically \(but not always\) prefixed with "`_`".
 
-Use "protected" methods or properties only if you access it from the object itself or an object that extends that object. \(For example as we do in [Step 19: Reuse Dialogs](Step_19_Reuse_Dialogs_1945396.md) of the *Walkthrough* tutorial.\) In the API Reference, protected functions are indicated by a label *Visibility: protected* below the description of the function.
+Use "protected" methods or properties only if you access it from the object itself or an object that extends that object. In the API Reference, protected functions are indicated by a label *Visibility: protected* below the description of the function.
 
 Always double check in the API Reference. If OpenUI5 changes the implementation in a future release, your code will break if you fail to follow this guideline.
 

diff --git a/docs/Step_10_Descriptor_for_Applications_8f93bf2.md b/docs/Step_10_Descriptor_for_Applications_8f93bf2.md
@@ -66,8 +66,9 @@ You can view and download all files at [Walkthrough - Step 10](https://openui5.h
 		"id": "app"
 	},
 	"dependencies": {
-	  "minUI5Version": "1.60",
+	  "minUI5Version": "1.93",
 	  "libs": {
+		"sap.ui.core": {}
 		"sap.m": {}
 	  }
 	},

diff --git a/docs/Step_16_Dialogs_and_Fragments_4da7298.md b/docs/Step_16_Dialogs_and_Fragments_4da7298.md
@@ -91,8 +91,6 @@ We add a new XML file to declaratively define our dialog in a fragment. The frag
 
 The syntax is similar to a view, but since fragments do not have a controller this attribute is missing. Also, the fragment does not have any footprint in the DOM tree of the app, and there is no control instance of the fragment itself \(only the contained controls\). It is simply a container for a set of reuse controls.
 
-We also add an `id` for our `Dialog` to be able to access the dialog from our `HelloPanel` controller.
-
 ***
 
 ### webapp/controller/HelloPanel.controller.js
@@ -111,17 +109,11 @@ sap.ui.define([
 			…
 		}*HIGHLIGHT START*,
 		onOpenDialog : function () {
-			var oView = this.getView();
 
 			// create dialog lazily
 			if (!this.pDialog) {
-				this.pDialog = Fragment.load({
-					id: oView.getId(),
+				this.pDialog = this.loadFragment({
 					name: "sap.ui.demo.walkthrough.view.HelloDialog"
-				}).then(function (oDialog) {
-					// connect dialog to the root view of this component (models, lifecycle)
-					oView.addDependent(oDialog);
-					return oDialog;
 				});
 			} 
 			this.pDialog.then(function(oDialog) {
@@ -133,25 +125,16 @@ sap.ui.define([
 });
 ```
 
-If the dialog in the fragment does not exist yet, the fragment is instantiated by calling the `Fragment.load` API with the following arguments:
-
--   The ID of the `HelloPanel` view
-
-    This parameter is used to prefix the IDs inside our fragment. There, we have defined the ID `helloDialog` for the `Dialog` control, and we can access the dialog via the view by calling `oView.byId("helloDialog")`. This makes sure that even if you instantiate the same fragment in other views in the same way, each dialog will have its unique ID that is concatenated from the view ID and the dialog ID.
+If the dialog in the fragment does not exist yet, the fragment is instantiated by calling the `loadFragment` API.
 
-    Using unique IDs is important, because duplicate IDs lead to errors in the framework.
+As you can see in the snippet above, we store the loading `Promise` of the dialog fragment on the controller instance. This allows us to handle the opening of the dialog asynchronously on each click of the `helloDialogButton` button.
 
--   The name of the fragment
-
-
-We add the dialog as "dependent" on the view to be connected to the lifecycle of the view’s model. A convenient side-effect is that the dialog will automatically be destroyed when the view is destroyed. Otherwise, we would have to destroy the dialog manually to free its resources.
+To reuse the dialog opening and closing functionality in other controllers, you can create a new file `sap.ui.demo.walkthrough.controller.BaseController`, which extends `sap.ui.core.mvc.Controller`, and put all your dialog-related coding into this controller. Now, all the other controllers can extend from `sap.ui.demo.walkthrough.controller.BaseController` instead of `sap.ui.core.mvc.Controller`.
 
 ***
 
 ### Conventions
 
--   Always use the `addDependent` method to connect the dialog to the lifecycle management and data binding of the view, even though it is not added to its UI tree.
-
 -   Private functions and variables should always start with an underscore.
 
 

diff --git a/docs/Step_17_Fragment_Callbacks_354f98e.md b/docs/Step_17_Fragment_Callbacks_354f98e.md
@@ -49,17 +49,10 @@ sap.ui.define([
 		},
 
 		onOpenDialog : function () {
-			var oView = this.getView();
 
 			if (!this.pDialog) {
-				this.pDialog = Fragment.load({
-					id: oView.getId(),
-					name: "sap.ui.demo.walkthrough.view.HelloDialog"*HIGHLIGHT START*,
-					controller: this*HIGHLIGHT END*
-				}).then(function (oDialog) {
-					// connect dialog to the root view of this component (models, lifecycle)
-					oView.addDependent(oDialog);
-					return oDialog;
+				this.pDialog = this.loadFragment({
+					name: "sap.ui.demo.walkthrough.view.HelloDialog"
 				});
 			} 
 			this.pDialog.then(function(oDialog) {
@@ -77,8 +70,6 @@ sap.ui.define([
 });
 ```
 
-As previously described, fragments are pure UI reuse artifacts and do not have a controller. However, you can pass a controller object to the `Fragment.load` API. For our dialog we reference the `HelloPanel` controller. However, the third parameter does not necessarily have to be a controller but can be any object. Just don't forget the `this` keyword.
-
 The event handler function is put into the same controller file and it closes the dialog by accessing the internal helper function that returns the dialog.
 
 ***
@@ -101,7 +92,7 @@ The event handler function is put into the same controller file and it closes th
 </core:FragmentDefinition>
 ```
 
-In the fragment definition, we add a button to the `beginButton` aggregation of the dialog. The press handler is referring to an event handler called `.onCloseDialog`, and since we passed in the reference to the `HelloPanel` controller, the method will be invoked there when the button is pressed. The dialog has an aggregation named `beginButton` as well as `endButton`. Placing buttons in both of these aggregations makes sure that the `beginButton` is placed before the `endButton` on the UI. What `before` means, however, depends on the text direction of the current language. We therefore use the terms `begin` and `end` as a synonym to “left” and “right". In languages with left-to-right direction, the `beginButton` will be rendered left, the `endButton` on the right side of the dialog footer; in right-to-left mode for specific languages the order is switched.
+In the fragment definition, we add a button to the `beginButton` aggregation of the dialog. The press handler refers to an event handler called `.onCloseDialog`. By using the `loadFragment` function to create the fragment content, the method will be invoked there when the button is pressed. The dialog has an aggregation named `beginButton` as well as `endButton`. Placing buttons in both of these aggregations makes sure that the `beginButton` is placed before the `endButton` on the UI. What `before` means, however, depends on the text direction of the current language. We therefore use the terms `begin` and `end` as a synonym to “left” and “right". In languages with left-to-right direction, the `beginButton` will be rendered left, the `endButton` on the right side of the dialog footer; in right-to-left mode for specific languages the order is switched.
 
 ***