After playing with the beta shipment of the UI Development Tookit for HTML5 aka SAPUI5 for a bit over the last week I took away a very positive first impression. The environment was straight forward to setup, the documentation detailed and useful, the code did what the documentation promised as far as I could tell and the resulting web application looks nice and clean and is responsive. That's already more than what I would generally expect from a beta program so a clear thumbs-up to the SAP product team on these aspects!
On the other side I could have done with better IDE support (new project wizard, code assist, etc.), but understand that's on it's way. What I was also missing was a more comprehensive example that shows how the various concepts hang together and where I could get a sense of how to best structure my project. I hope we'll see that included in the next version of the documentation, but in the meantime here is what worked for me.
Here's my sample scenario
So let's get started. The target I set myself was to build a simple event calendar where the panel below the events calendar would show the details of the selected event.
I was mostly interested in the UI aspects so was just going to simulate a data source rather than actually write one.
Setting up the environment
It usually pays of very quickly to have your IDE tightly integrated with the test environment and I found that's also true for SAPUI5 development, especially since Eclipse wasn't able to validate the code I wrote on the spot so I had to do lots of testing in the browser. I therefore started with importing the "getting-started-sample.war" file that comes with the beta shipment into Eclipse (Indigo SR1) and stripped it down to just an index.html, but kept the .jar files and the web archive descriptor. Once I got this new project deployed successfully into my local Tomcat 7.0 server and any changes I made to it in Eclipse were automatically synchronised into Tomcat I knew I was ready to go.
Model View Controller
After spotting the MVC support in the SAPUI5 documentation I quickly settled on the following structure to split up the various concerns of the UI into manageable units.
The 'index.html' bootstraps the SAPUI5 libraries and includes my main JavaScript application file, which I called 'app.js'.
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="X-UA-Compatible" content="IE=edge" />
<title>Events</title>
<script id="sap-ui-bootstrap" type="text/javascript"
src="resources/sap-ui-core.js"
data-sap-ui-theme="sap_goldreflection"
data-sap-ui-libs="sap.ui.ux3, sap.ui.commons, sap.ui.table">
</script>
<script src="app.js">
</script>
</head>
<body class="sapUiBody">
<div id="uiArea"></div>
</body>
</html>Inside the body tag you'll notice a 'uiArea' div placeholder which is where the 'app.js' script will place the SAPUI5 application shell.
This 'app.js' is also where all the different MVC components are bound together.
//construct and configure the app shell with a single worksetitem
var shell = new sap.ui.ux3.Shell("objectivesAppShell", {showSearchTool:false, showInspectorTool:false, showFeederTool:false, showLogoutButton:false});
shell.addWorksetItem(new sap.ui.ux3.NavigationItem({key : "wi_Events", text : "Events"}));
//construct the view
var eventsView = sap.ui.view({ type: sap.ui.core.mvc.ViewType.JSON,
viewName: "mypackage.Events",
controller: sap.ui.controller("mypackage.Events")
});
//load and bind the model
var eventsModel = new sap.ui.model.json.JSONModel();
eventsModel.loadData("Events.json");
eventsView.setModel(eventsModel);
var eventsList = eventsView.byId("eventList");
eventsList.bindRows("events");
//place view in app shell, app shell in uiArea
shell.setContent(eventsView);
shell.placeAt("uiArea");The "mypackage.Events" view is constructed from a JSON file that by convention needs to be called 'Events.view.json' and lives in '/resources/mypackage'.
{
"Type":"sap.ui.core.mvc.JSONView",
"content": [{
"Type":"sap.ui.table.DataTable",
"id":"eventList",
"title":"Events Calendar",
"visibleRowCount":5,
"selectionMode":"Single",
"columns" : [{
"Type":"sap.ui.table.Column",
"label":"Date",
"width":"20%",
"template": {
"Type":"sap.ui.commons.TextField",
"value":"{date}"
}
},
{
"Type":"sap.ui.table.Column",
"label":"Event",
"template": {
"Type":"sap.ui.commons.TextField",
"value":"{title}"
}
},
{
"Type":"sap.ui.table.Column",
"label":"Location",
"width":"20%",
"template": {
"Type":"sap.ui.commons.TextField",
"value":"{location}"
}
}],
"rowSelect":"onRowSelect"
},
{
"Type":"sap.ui.commons.Panel",
"id":"eventDetail",
"title":{
"Type":"sap.ui.commons.Title",
"text":"{title}"
},
"showCollapseIcon":false,
"content":[{
"Type":"sap.ui.commons.TextView",
"text":"{description}"
}]
}]
}Alternatively this view could have been loaded from an XML file or created programmatically in JavaScript. I personally prefer the declarative approach for view definition since it enforces a clean separation between view creation, data bindings to the model and controller logic. And who knows, maybe we're even going to get some visual layout tooling to produce this JSON View file more easily.
The "mypackage.Events" controller is a JavaScript file that by convention needs to be called 'Events.controller.js' and also lives in '/resources/mypackage'. This is really where the separation between view and controller starts to pay off since it's now easy to spot and comprehend the actual logic and event handlers of this little application.
sap.ui.controller("mypackage.Events", {
onInit : function() {
this.byId("eventDetail").setVisible(false);
},
onRowSelect : function(event) {
eventDetail = this.byId("eventDetail");
eventDetail.bindContext(event.getParameter("rowContext"));
eventDetail.setVisible(true);
}
});And finally, here's the data that I loaded into the model via the 'Events.json' file.
{
"events" : [{
"date":"October 15-19",
"title":"SAP TechEd 2012",
"location":"Las Vegas",
"description":"SAP TechEd is the premier technical conference offering over 1,000 hours on SAP technologies, focused on SAP NetWeaver, analytics, and mobile platforms. Enhance your skills by attending hands-on workshops, demo-driven lectures, and Q&A sessions on the latest developments in analytics, mobile, cloud, database, and in-memory computing. Make valuable connections with peers and distinguished IT professionals from our SAP community."
},
{
"date":"November 13-15",
"title":"SAPPHIRE NOW 2012",
"location":"Madrid",
"description":"Transform your business with essential information and best practices for business executives, lines of business, and IT decision makers, and business managers."
},
{
"date":"November 13-16",
"title":"SAP TechEd 2012",
"location":"Madrid",
"description":"Run smarter with education for IT professionals. Over 500 hours of hands-on workshops and in-depth technical training plus access to all SAPPHIRE NOW content."
},
{
"date":"November 28-30",
"title":"SAP TechEd 2012",
"location":"Bangalore",
"description":"Registration opens this summer. Check back for event details."
},
{
"date":"December 4-5",
"title":"SAP TechEd 2012",
"location":"Shanghai",
"description":"Registration opens this summer. Check back for event details."
}]
}Assuming that a backend service would produce an identical output it would be trivial to later swap out this dummy data with a live data source. Using dummy data can also be useful in other contexts, e.g. to bridge the time on a project until the actual data source becomes available or if the frontend developer doesn't have (continuous) access to the backend service.
So what do you think? Is this a structure that could scale to larger SAPUI5 projects? How would you structure your SAPUI5 project?
- SAP Managed Tags:
8 Comments
