OpenUI5 Documentation Update 05.10.2024

docs/Step_30_Routing_and_Navigation_TypeScript_6173e3d.md

@@ -248,15 +248,15 @@ import { SearchField$SearchEvent } from "sap/m/SearchField";
 import Filter from "sap/ui/model/Filter";
 import FilterOperator from "sap/ui/model/FilterOperator";
 import ListBinding from "sap/ui/model/ListBinding";
-import Component from "../Component";
+import UIComponent from "sap/ui/core/UIComponent";
 
 /**
  * @namespace ui5.walkthrough.controller
  */
 export default class App extends Controller {
 		…
     onPress(): void {
-        const router = (<Component> this.getOwnerComponent()).getRouter();
+        const router = UIComponent.getRouterFor(this);
         router.navTo("detail");
     }
 };

docs/Step_31_Routing_with_Parameters_TypeScript_afd5eb6.md

@@ -105,7 +105,7 @@ import { SearchField$SearchEvent } from "sap/m/SearchField";
 import Filter from "sap/ui/model/Filter";
 import FilterOperator from "sap/ui/model/FilterOperator";
 import ListBinding from "sap/ui/model/ListBinding";
-import Component from "../Component";
+import UIComponent from "sap/ui/core/UIComponent";
 import Event from "sap/ui/base/Event";
 import ObjectListItem from "sap/m/ObjectListItem";
 
@@ -115,9 +115,9 @@ import ObjectListItem from "sap/m/ObjectListItem";
 export default class App extends Controller {	
 	…
     onPress(event: Event): void {
-        const item = <ObjectListItem> event.getSource();
+        const item = event.getSource() as ObjectListItem;
 
-        const router = (<Component> this.getOwnerComponent()).getRouter();
+        const router = UIComponent.getRouterFor(this);
         router.navTo("detail", {
             invoicePath: window.encodeURIComponent(item.getBindingContext("invoice").getPath().substr(1))
         });
@@ -143,7 +143,7 @@ The `bindElement` function creates a binding context for an OpenUI5 control and
 
 ```js
 import Controller from "sap/ui/core/mvc/Controller";
-import Component from "../Component";
+import UIComponent from "sap/ui/core/UIComponent";
 import { Route$PatternMatchedEvent } from "sap/ui/core/routing/Route";
 
 /**
@@ -152,7 +152,7 @@ import { Route$PatternMatchedEvent } from "sap/ui/core/routing/Route";
 export default class Detail extends Controller {
 
     onInit(): void {
-        const router = (<Component> this.getOwnerComponent()).getRouter();
+        const router = UIComponent.getRouterFor(this);
         router.getRoute("detail").attachPatternMatched(this.onObjectMatched, this);
     }
 

docs/Step_32_Routing_Back_and_History_TypeScript_ae61211.md

@@ -46,18 +46,17 @@ If no navigation has happened before, we get a reference to the router and use t
 
 ```js
 import Controller from "sap/ui/core/mvc/Controller";
-import Component from "../Component";
+import UIComponent from "sap/ui/core/ UIComponent";
 import { Route$PatternMatchedEvent } from "sap/ui/core/routing/Route";
 import History from "sap/ui/core/routing/History";
-import UIComponent from "sap/ui/core/ UIComponent";
 
 /**
  * @namespace ui5.walkthrough.controller
  */
 export default class Detail extends Controller {
 
     onInit(): void {
-        const router = (<Component> this.getOwnerComponent()).getRouter();
+        const router = UIComponent.getRouterFor(this);
         router.getRoute("detail").attachPatternMatched(this.onObjectMatched, this);
     }
 
@@ -78,7 +77,7 @@ export default class Detail extends Controller {
             const router = UIComponent.getRouterFor(this);
             router.navTo("overview", {}, true);
         }
-    }    
+    }
 };
 ```
 

docs/Step_33_Custom_Controls_TypeScript_3cc020e.md

@@ -349,10 +349,9 @@ In the `onObjectMatched` method, we call the `reset` method to make it possible
 
 ```js
 import Controller from "sap/ui/core/mvc/Controller";
-import Component from "../Component";
+import UIComponent from "sap/ui/core/ UIComponent";
 import { Route$PatternMatchedEvent } from "sap/ui/core/routing/Route";
 import History from "sap/ui/core/routing/History";
-import UIComponent from "sap/ui/core/ UIComponent";
 import MessageToast from "sap/m/MessageToast";
 import ProductRating, { ProductRating$ChangeEvent } from "../control/ProductRating";
 import ResourceBundle from "sap/base/i18n/ResourceBundle";
@@ -364,7 +363,7 @@ import ResourceModel from "sap/ui/model/resource/ResourceModel";
 export default class Detail extends Controller {
 
     onInit(): void {
-        const router = (<Component> this.getOwnerComponent()).getRouter();
+        const router = UIComponent.getRouterFor(this);
         router.getRoute("detail").attachPatternMatched(this.onObjectMatched, this);
     }
 

docs/Step_35_Device_Adaptation_TypeScript_ab8ed1b.md

@@ -139,10 +139,9 @@ In the `Detail` controller we simply add the view model with our currency defini
 
 ```js
 import Controller from "sap/ui/core/mvc/Controller";
-import Component from "../Component";
+import UIComponent from "sap/ui/core/ UIComponent";
 import { Route$PatternMatchedEvent } from "sap/ui/core/routing/Route";
 import History from "sap/ui/core/routing/History";
-import UIComponent from "sap/ui/core/ UIComponent";
 import MessageToast from "sap/m/MessageToast";
 import ProductRating, { ProductRating$ChangeEvent } from "../control/ProductRating";
 import ResourceBundle from "sap/base/i18n/ResourceBundle";
@@ -160,7 +159,7 @@ export default class Detail extends Controller {
         });
         this.getView().setModel(viewModel, "view");   
 
-        const router = (<Component> this.getOwnerComponent()).getRouter();
+        const router = UIComponent.getRouterFor(this);
         router.getRoute("detail").attachPatternMatched(this.onObjectMatched, this);
     }
 		…

docs/Step_6_A_First_OPA_Test_1b47457.md

@@ -88,7 +88,7 @@ sap.ui.define([
 });
 ```
 
-Let’s add our first new OPA test to the `WorklistJourney.js` file. We describe all test cases related to the worklist logic. We can see that there is already a test `Should see the table with all posts` defined that checks if the table contains the expected number of items. There is a function `opaTest` that initiates a test description and receives a test description as the first argument as well as a callback function as the second argument. This format is similar to the unit test function `QUnit.test` except for the three arguments of the callback function that are specific to OPA.
+Let’s add our first new OPA test to the `WorklistJourney.js` file. We describe all test cases related to the worklist logic. We can see that there is already a test `Should see the table with all posts` defined that checks if the table contains the expected number of items. There is a function `opaTest` that initiates a test and receives a test description as the first argument as well as a callback function as the second argument. This format is similar to the unit test function `QUnit.test` except for the three arguments of the callback function that are specific to OPA.
 
 The three objects `Given`, `When`, `Then` are filled by the OPA runtime when the test is executed and contain the `arrangements`, `actions`, and `assertions` for the test. The "Given-When-Then" pattern is a common style for writing tests in a readable format. To describe a test case, you basically write a user story. Test cases in this format are easy to understand, even by non-technical people.
 
@@ -194,14 +194,14 @@ sap.ui.define([
 
 As you can see, the OPA page object is constructed with the call `Opa5.createPageObjects` and a `configuration` object that contains the actions and assertions properties.
 
-For our test case we need to add an action `iPressOnMoreData` and an existing assertion `theTableShouldHaveAllEntries`. OPA tests are running asynchronously, so each action and assertion starts with a `waitFor` statement. The OPA run time will check and wait for the condition to be fulfilled every 400 ms by polling. If the condition is met, the `success` function of the configuration is called. If the condition is still not fulfilled after a certain amount of time \(by default it is 15 seconds but this can be configured\) the test will fail.
+For our test case we need to add an action `iPressOnMoreData` and an existing assertion `theTableShouldHaveAllEntries`. OPA tests are running asynchronously, so each action and assertion starts with a `waitFor` statement. The OPA runtime will check and wait for the condition to be fulfilled every 400 ms by polling. If the condition is met, the `success` function of the configuration is called. If the condition is still not fulfilled after a certain amount of time \(by default it is 15 seconds but this can be configured\) the test will fail.
 
 Let’s start with the action `iPressOnMoreData`. We define a `waitFor` statement with the current view and the table. Those IDs are stored as internal variables in the `require` statement above and are available in all tests. OPA will now try to find the table based on IDs. As soon as the table is available on the screen and it can be interacted with \(it is visible, not busy,...\), the `Press` action is invoked, if not, the error message is displayed and the test fails. When executed on a table, the `Press` action will simulate that a users chooses the *More Data* button.
 
 > ### Note:  
 > The `Press` action depends on the control that it is triggered on and has a default behavior for most UI controls. If you, for example, execute `Press` on a `sap.m.Page`, this will trigger the *Back* button's `Press` event. This behavior can be overridden by passing an ID as argument to the action. For more information, see the [API Reference: `sap.ui.test.actions.Press`](https://sdk.openui5.org/api/sap.ui.test.actions.Press). 
 
-The assertion `theTableShouldHaveAllEntries` is structured similarly, but it does not trigger an action. Here, we use the `success` function of `waitFor` to assert if our application is in the expected state. This state is defined by the matchers \(in our case we expect that the list contains 23 items by using the `AggregationLengthEquals`. The `success` function does not execute the additional checks that are needed for triggering an action. the liste does not have to be `interactable` to verify that the state of the application is correct..
+The assertion `theTableShouldHaveAllEntries` is structured similarly, but it does not trigger an action. Here, we use the `success` function of `waitFor` to assert if our application is in the expected state. This state is defined by the matchers \(in our case we expect that the list contains 23 items by using the `AggregationLengthEquals`. The `success` function does not execute the additional checks that are needed for triggering an action. The list does not have to be `interactable` to verify that the state of the application is correct.
 
 With this helper object we can simply check the length of the table aggregation `items` to the expected number of items. We have 23 entries in our local mock data that we also use for this integration test. You can see that the number of items is actually hard-coded in the test. So only if the table has exactly 23 items, the matcher is evaluating to `true` and the assertion is passed successfully.