Key Development Concepts

HTML and JavaScript

HTML and JavaScript applications have traditionally been difficult to organize and maintain because they do not come with any built-in organizational tools or guidelines. As a result, web applications have a tendency become large collections of interdependent files with markup and business logic spread throughout.

However, if you apply proven organizational and architectural concepts, and you enforce intelligent conventions, you can greatly improve the quality and life cycle of JavaScript applications and produce solutions that are as clean, robust, and maintainable as in any other language or platform.

JavaScript is a prototypical object-oriented language. It does not have conventional classes, yet it is a fully object-oriented language. This tends to mislead developers who don’t fully understand prototypical inheritance and object composition. The Geocortex HTML5 Framework uses JavaScript in a manner that aims to be as simple and effective as possible.

The Geocortex HTML5 Framework uses the Dojo library for a few key concepts. One of the places that Dojo is most frequently used is when declaring object types using the dojo.declare method. This method creates objects that behave similar to traditional classes seen in other languages. For more information about Dojo, see

The HTML5 Viewer uses jQuery for some light UI work. For more information about jQuery, see

Separation of Concerns

A clean separation and delineation of business logic and presentation code is desirable in almost any software application. Client-side web applications have historically been quite bad at this, and it is a significant source of pain for those tasked with debugging, maintaining, and augmenting existing JavaScript applications.

Web applications commonly mix markup and script code across both HTML and JavaScript files. It is quite common to see large portions of user interfaces generated and styled in code that is buried in a script file for a future developer to hunt down. Presentation code is quite often mixed and interwoven with business logic.

When you separate user-interface markup, styling, and code from its underlying business logic, web applications become easier to understand and maintain.

In order to facilitate this separation of concerns, the Geocortex HTML5 Framework separates resources into the following groups:

These application resources interact with each other so that they function as a cohesive unit, while being separate both logically and semantically in the implementation.

There are two key concepts that allow this separation to work effectively:

Model-View-ViewModel (MVVM)

Model-View-ViewModel is an architectural pattern based on Model-View-Controller (MVC), a pattern for developing user interfaces that separates the internal representations of information from the way information is presented to or accepted from the user.

There are many good online resources to familiarize you with MVVM. We recommend becoming familiar with the basic concepts as a minimum. The HTML5 Viewer SDK includes samples of MVVM in action.

There are three distinct entities in the MVVM pattern:

Example Comparison of Traditional and MVVM Applications

An example might be an interface component that displays a list of parcels that meet a set of criteria.

In a traditional web application, a parcel list user interface would be generated programmatically by iterating over a number of parcel objects and manually building HTML markup using string concatenation or Document Object Model (DOM) manipulation. This code would be in the web page, in script tags, or it may be buried deep in a script file. The styles for this component would be to be in a master Cascading Style Sheet (CSS) file, or even declared inline where the user interface markup is generated.

In an HTML5 Viewer application, the parcel list component is separated into its constituent parts. The folder containing the source for this module would contain the following:

Even for those not familiar with MVVM, the duties of each file should be somewhat clear. CSS styles and HTML markup are separated into their own files and define the layout and style of the interface component. The user interface (UI) code and business code is not mixed. The UI code for the parcel list interface component has its own code file (ParcelsView.js). The business code (ParcelsViewModel.js) also has its own file, as the two have separate concerns.

The Geocortex HTML5 Framework provides mechanisms that allow these pieces to work together while being defined separately. A data-binding engine allows view markup to bind to fields in the view model and event handlers in the view. In addition, view code can access view model members and can call view model methods. View markup is styled by view CSS.

This organizational style of UI development lends itself well to rapid development and the creation and maintenance of reusable controls and widgets.

Data Binding in HTML

The other key component that allows for a separation of concerns is data binding. Data binding provides a clean and powerful way to create user interfaces without writing boilerplate code that unnecessarily queries and modifies the DOM.

Data binding provides the glue between views and view models. By using data binding expressions, developers are able to declaratively specify relationships between HTML elements, view model properties, and view events.

Example Comparison Continued

We can continue with the example of the component that displays a list of parcels.

In traditional client-side web development, the parcel list user interface is typically created and updated manually to reflect the underlying list of parcels. Libraries like jQuery and Dojo make this kind of task easy.

Consider a typical line of jQuery, used to append a parcel to our list:

  $(".parcels ul").append("<li>" + parcel.ownername + "</li>");

This code looks fine—it is simple and terse—but it suffers from significant drawbacks. For example, every time this code is run to add a new parcel to the list, it is probably invoking the selector for .parcels ul. Depending on the complexity of the page, this can be a lot of overhead for a task that may be repeated hundreds or thousands of times, especially if we are searching from the root of the page. On a mobile device, this becomes a significant factor.

In addition, this code example mixes markup and code. What happens if a designer or developer wants to change from using a list to using a table? They would have to hunt down this piece of code, whose location probably has little correlation with what is seen in a DOM inspector tool.

An experienced JavaScript developer might point out that in this example the selector could be precached, the query limited to a particular element, and that a call to end() would save unnecessary work. The data binding engine performs this type of work under the hood so that developers do not have to.

A much better solution to the traditional style of DOM manipulation would be to remove the burden of it from the developer and have the system perform it in an efficient manner.

In an MVVM implementation the parcels view markup would be:

<div class="parcels">
   <ul data-binding="{@source: parcels}">
      <!-- Template item for each member of the parcels collection. -->
      <li data-binding="{@template-for: parcels}{@text: ownerName}"></li>

In the Geocortex HTML5 Framework, this code example has the same functionality as the previous hypothetical piece of sample traditional code. The difference is that there is no developer code involved in populating the UI. The relationship between data and the presentation is declared in the View markup.

The Geocortex HTML5 Framework introduces a custom data-binding HTML attribute that declaratively associates UI elements with view model fields and event handlers in the view code.

In the above example, the unordered list ul has a @source binding to a parcels collection of an underlying view model, and contains a single list item li as a template that has a @text binding to an ownerName attribute.

For each member of the parcels collection, a list item li element is created and its own binding expressions satisfied against each parcel object in the collection.

The end result of this example is a list of parcel owner names. This UI component automatically updates whenever the underlying collection of parcels is changed in some way.

The data binding engine picks up binding expressions when UI markup is added to the page as a view. Views are inspected and all binding expressions parsed and resolved up front, leaving the developer free to deal with business logic instead of writing UI event handlers and worrying about other tedious interface considerations.

The data binding approach is effective to the developer primarily because he or she escapes the time costs in writing and maintaining brittle UI manipulation code. It is also beneficial to mobile performance, as bindings are wired up once by the binding engine and resolved into event handlers and closures behind the scenes. The structure of View HTML does not need to be repeatedly queried, and modification is done effectively by the system, resulting in a UI that is efficient at both design time and run time.

See also...

Data Binding

© 2021 VertiGIS North America Ltd. All Rights Reserved.

Documentation Version 4.14