We're using the Model View Controller (MVC) concept, and this starts with a root View that the Component instantiates - the App view.
Right now, the error in the console is suggesting that an App view, specifically the file App.view.xml, is missing. Let's take this opportunity to step back and look at what we're going to build.
The app view is rather simple, in that it contains just a single control - an sap.m.SplitApp - and does not have a corresponding controller. There is no requirement for a controller as the routing and navigation logic is provided by the Router that we've already defined.
Further, there's no requirement for any great detail in the SplitApp, as the aggregation content is also controlled by the Router. This is what the App view looks like, in its entirety:
<mvc:View xmlns:mvc="sap.ui.core.mvc" displayBlock="true" xmlns="sap.m"> <SplitApp id="idAppControl" /> </mvc:View>
A SplitApp is a so-called 'container' control, and inheriting from sap.m.NavContainer, has two container sections, in the form of aggregations: masterPages and detailPages. These aggregations, as we already saw in the Routing configuration in the Component, are managed by the Router, and we don't need to specify anything directly here. While we're already getting some separation of concerns, it's more from the fact that we're using a container control. We're going to go one level deeper and use the MVC approach within the contained controls. The 'pages' suffix of these aggregation names suggest that the sap.m.Page is a candidate for aggregation, however, we're aggregating views, as we can see in the Routing configuration. This is a common pattern.
Aggregating views within the SplitApp container control allows us to develop the different parts of the app independently, handling the UI and logic in discrete sections. We've already seen the component overview schematic in Part 1, so let's look at a tree-based summary of the controls and MVC elements now (all filenames are relative to the app's root folder):
control:UIComponent (Component.js) | +-- view:App (view/App.view.xml) | +-- control:SplitApp | +-- aggregation:masterPages | | | +-- view:Master (view/Master.view.xml) | | | +-- controller: Master (view/Master.controller.js) | +-- aggregation:detailPages | +-- view:Detail (view/Detail.view.xml) | | | +-- controller:Detail (view/Detail.controller.js) | +-- view:NotFound (view/NotFound.view.xml) | +-- view:AddProduct (view/AddProduct.view.xml) | +-- controller:AddProduct (view/AddProduct.controller.js)
We'll add the App view, and also a couple of temporary skeleton XML declarations for the Master and Detail views (this is mostly so we can see a little bit of progress). Our skeleton XML declarations for the Master and Detail views look like this:
<mvc:View xmlns:mvc="sap.ui.core.mvc" />
In other words, completely empty views. Now our app folder content now looks like this:
tdg/ | +-- i18n/ | | | +-- messageBundle.properties | +-- view/ | | | +-- App.view.xml | +-- Detail.view.xml | +-- Master.view.xml | +-- Component.js +-- index.html +-- MyRouter.html
At this stage things look a little more interesting than the previous empty screen. We can see the core structure of the SplitApp.
There are no relevant error messages in the console - the runtime is delivering exactly what we asked for (a couple of empty views in the SplitApp container control).
In fact, because there's now actually something visible, let's have a look at an alternative screenshot, where the browser window is maximised to full screen:
Here we can see that the Master and Detail aggregation proportions remain, despite the extreme width of the browser window; there are margins on the left and right sides. This is due to the sap.m.Shell control that we introduced in the index.html.