Yesterday I published a new video on Rethinking smartUI on Youtube. If you havnt seen yet, here is the short video. In this posts, we’ll go though the technical aspects of this new kind of approach to smartUI. This demo is a Document Pad (or short DocPad), displaying all document properties in a SCIFI GUI arrangement.
This is Part 1 of a multipart post covering all aspects of this Docpad.
The post parts until now
Part 4-A The Javascript Part 1
Part 3 The Infrastructure and the CSS
Part 1: Overview
This demo is supposed to do this:
- Demonstrate the usage of html5, javascript 6 and css3. Especially how to use this modern components inside the smartUI framework. For example, the famous parse function in the standard demo widget will change this way:
js5
parse: function (response) {
// All attributes are placed below the data key
return response.data;
}
js6
parse: (response) => response.data
- Compare the methods of getting data via REST using the methods
- Model (as usual in Backbone)
- XMLHttpRequest (the good old XMLHttpRequest as used since long)
- Fetch (the modern javascript 6 method to get REST data)
- Not used: async/await. Despite the fact that async/await is very handy, this appeared in javascript 8 and is beyond the scope of the demo.
- Exploit the power of css by using
- different display methods as Grid and Table
- use panels in a cube. Origionally this was planned as moveable 3D cube. In this case, all metadata were written on the sides of the cube. Here is a very good technical description how to do it. Unfortunately the cube idea seems to be very impractical for the demo and was dropped
- “burning borders”, fog and animations as element of the UI
- provide an additional print style sheet to make this screen infos printeable in a normal way
- Except some Icons of Bootstrap, nothing is to be used from Bootstrap. These Icons can be replaced by those in the fontawesome font
- JQuery is not used
- These Content Server REST commands are used
- The log in is done in the index.html page, but when used as a dashboard widget the user is already logged in. If a separate login panel is required (p.ex. for a stand aloane dashboard on a tablet) then its necessary to provide a login via post […]/v1/auth
- then the user info is retrieved via get […]/v1/auth
- if the user has stored a photo in his profile, then the photo is retrieved by get […][photo-url] and then inserted in the DOM.
- Then the standard Node-Picker Control is called. All Node-Picker interactions with the server are managed by this control. As a result, the nodeid of the selected Document is returned.
- Next, the DAPINode infos of the selected node are retrieved by get […]/v1/nodes/{id}
- for the “created_by” and “modified_by” there is only a nujmber returned, the userid. For this two cases, the username is retrieved from the server by get […]/v1/members
- Its always nice to exploit the thumbnail of the document to the user. This is done by get […]/nodes/{id}/thumbnails/medium/content
- To get all other data , a special trick is used. The command get […]/v1/forms/nodes/update returns all categories and the othere nodeinfos using one REST call. This commmand takes a while to execute, so the user is entertained using some css animations.
In the next week, we explore the infrastructure of this Docpad demo.