Some Best Practices derived from the SAP Fiori Templates in SAP Web IDE
In 2015, the attentive observer will have witnessed an evolution of static demo applications in the demokit into real SAP Fiori templates in SAP Web IDE. Kickstarting application development has never been easier. But besides planting these applications on SAP Fiori home turf, this process also affected the programming model, helped to close gaps and fostered the integration and usability of features across the different technological layers in general (Runtime, Controls, UShell). Now it’s about time to read between the lines of code and flesh out some things that really make developing apps with SAPUI5 much easier.
But before we get started let`s first have a look what we are talking about. There are actually several ways to make use of the example app coding I will talk about:
- Find them in the demoapps section of the SAPUI5 Demokit (actually you will find them in the OpenUI5 Demokit as non-flp versions as well).
- Generate your own app from templates directly in SAP Web IDE.
- Browser the code on github (OpenUI5 versions only: master-detail / worklist)
- Learn how to build on top of it (sneak peak of a template tutorial on openui5-beta)
Full MVC plus light view models
Data binding is something you have to embrace. It works best if you assess it with the right level of abstraction. In the end it’s about nothing more than having the ability to keep things in sync. The programming model in SAPUI5 with its controls, their bindable properties and descriptive xml-views paired with functional js-controllers means that view models are undeniably the way to centrally orchestrate your views with one dedicated interface. If only everything in life was as easy as calling ‘setProperty’ on one of your models…
Still, full MMVC is possible, but for lightweight SAP Fiori applications, a model that simply controls the state of your view might make sense in most use cases.
Descriptor aka manifest.json
Being descriptive is not just a matter of serialization. But it still helps in that regard. Thanks to the new descriptor concept in SAPUI5, all application-specific configuration relevant for the external technical environment is now aggregated into one central file. It’s as simple as not having to read an entire book if you can already judge it by its cover. Machines like it that way. And your app development routines will also profit from that. Access the descriptor attributes via API and safe lines of code by descriptive i18n and OData model creation and configuration.
Here’s more documentation about this.
One of my favorites to be honest. Although this guy is not even a controller, he is the most instantiated in your application. And because everyone who writes code runs into the dilemma of repeating himself on a daily basis, we all should love him. Put all your reusable functionality on his shoulders. He can handle it, and he’ll carry these generics through your application. And once you reach the point where you need to be more specific: simply override in this child!
Your app is nothing without its views. The old world of sap.ui.core.routing.Router in SAPUI5 was dark and inscrutable. Although it was possible to create deep links to specific routes, do hash-based navigation and on-demand view instantiation, its hands did not reach very far. Implementing complex UI-patterns like master-detail or even cross-pattern with routing was no fun at all, leaving you to deal with complex sub-route configurations.
The new contender for giving you a masterclass in routing is the sap.m.routing.Router
It comes with more detailed configuration options: By exposing targets to the developer, for instance, it’s now possible to define multiple targets per route. No more having to deal with complex cascading configuration into sub-routes, instead a clear route – target relationship. On top of this, check out greedy routes, catchall config, asynchronous view loading and much more. You can sure expect a lot from this ‘new guy in town’.
If you think structuring your application is a no-brainer, you’ve probably never developed in a huge ecosystem made up of various technologies, tools and dependencies. Just think of questions like how to separate tests from productive code (and this is not only about test files). Think of CI: how can this work if your test suite
s are all scattered around individual apps? Or even worse: not there at all? When it comes to maintenance or bug fixing, it becomes even more obvious that some conventions really help to speed up the process. It`s like in your
local supermarket: you’ll find your milk next to the cheese and all veg in one place. Embrace uniformity! Anything else makes no sense!
Inside the templates, we see the MVC footprint very clearly. Usage of the model folder for all files that manipulate your data, the controller folder for all your hard working application logic, and the view folder for all views and fragments. If you really need an utils folder for all your little helpers, you might have to think about making some clear decisions regarding the responsibilities of your assets. Finally there is a folder for everything surrounding the mock server (metadata, annotations, and your local server logic), a test folder for test files and standalone runnables (yes, this is a component-based application, no index.html needed) and finally the Component.js next to the manifest.json on the top level of the app to rule them all.
Mock server handling
Nope, a mock server is not something you can order at your local hardware retailer! And yes, it is something that comes with SAPUI5… but once again nope, it’s not SAPUI5’s responsibility to provide its functionality out of the box. Mock server is an API. And just like all other things in SAPUI5 are handled, you have to instantiate it, configure it and then enjoy the work it does for you. Full control but also full responsibility. That is the way to go.
Use it to mock your OData service for offline development, do ninja-stuff to test your error handling and finally mock whatever path you want. Inspiration can be found here, and pure documentation here.
Content densities (compact vs. cozy)
If you want to experience compact and cozy, you simply have to open the Explored app and click on the gear icon in the top right corner of the master list. Here you’ll find one setting called “Compact Content Densities”. Switch it on and you’ll get the entire Explored app displayed in the more desktop-friendly compact mode while the default for the sap.m library displays in “cozy” for mobile scenarios (which is in fact a throw-back to the past when the “m” in sap.m stood for mobile, whereas you could now say the m stands for modern).
Technically this is nothing but CSS. In the case of the Explored app, this class is set straight to the body tag of your html. All the controls below have selectors in their CSS that wait for this in the body to tick in and influence appearance. Now assume you will run your application in a container like the SAP Fiori launchpad and this will potentially control this via settings, as we find in Explored. There has to be a contract, and this is the body tag to allow one to override the other. The logic in the Component.js will help you make the right assumptions regarding what your container already did for you (plus a default selection if nothing has been set) and the right class will be set to the App-control in the App.controller.js. Also use this logic down the line to this class, to controls in the static area of your DOM like sap.m.Dialog for instance.
Use SAP Web IDE
Ok! I have to confess this one isn’t really a best or “good” practice. Let`s call it a teaser. In the end you decide for yourself, but let me give you some reasons why developing apps with SAPUI5 and SAP Web IDE makes perfect sense.
First of all, SAP Web IDE builds on top of SAPUI5 – it actually uses SAPUI5 internally and was built to develop SAPUI5 applications. This is not just to prove that SAPUI5 is a powerful toolset, it also means that some developer dreams are finally close to coming true:
Think about WYSIWYG (aka Layout Editor; drag and drop to model your views), Descriptor Editor for the manifest.json (no more wasting time looking up complex configuration options), code snippets (tests, views, controllers – forget the obvious, let`s write more code instead) and many more cool things. Just check it out.
And once you’re on top of it, start extending the tool itself. Build your own templates, tools, side panels and much more. It’s an open party and you’re always invited! All you need is the documentation to get started
Final Words? Not this time! Everything’s been said already. Now it`s up to you to jump on the template train and get your project started!