Case Study: HTML5 Timesheet Tracking

The Client: Keyhole Software, Internal

Project Category: Development

Services Performed: Requirements Definition, Application Development, Data Migration, Mobile Development


This newly-created web application is how Keyhole Software employees keep track of time worked. It is accessible from a desktop, tablet, and any mobile device with a browser. Additionally, we have implemented Android and iOS native applications that interact with the same JSON endpoints that the browser-based UI uses.

Application Functionality Use Cases

LDAP-based Authentication, utilizing Atlassian Crowd:

LDAP Authentication

Once authenticated, users can create and edit timesheet entries based on the week. Administration user roles have access to reporting features and timesheet approval options based on this data. Reports are defined as Eclipse BIRT reports.

White Paper Case Study- JS Enterprise 2

User identification, as well as the applications and roles they have the authority to access, are stored in an LDAP repository. Administrator roles can maintain groups or users.

HTML5 Case Study3

How It Was Built

The application’s server side portions are built using Java EE technology. The application is contained inside an Apache/Tomcat application server hosted on an Amazon EC2 instance. System data is stored in a MySQL relational database.

Front End

The application’s user interface applies the following frameworks:

  • Bootstrap– an open source framework for the UI component, the look and feel of the application. It includes styling for typography, navigation and UI elements. One of the main reasons we chose Bootstrap as a viable solution was its responsive layout system, with which the user interface automatically scales to various devices (i.e. desktop, tablet, mobile).
  • jQuery, Require.js, and Backbone.js – JavaScript frameworks that provide Document Object Model (DOM) manipulation, dependency management and modularization, and Model View Controller and HTML templating support. And, all of them reside within a client browser.

Server Side

Application logic and data access to MySQL was implemented as server side Java endpoints. These endpoints were accessible via RESTful URLs via HTTP. Endpoints were created using Java technology and are contained by the Java EE application server. Plain old Java objects (POJO) modeled application data entities, which were mapped to the relational data source using an Object Relational mapper.

The following server side frameworks were used:

  • khsSherpa– a POJO-based RESTful JSON endpoint framework. Provides a built-in authentication mechanism.
  • Spring IOC and Spring Authentication – Spring’s dependency management was used to configure application logic and and data access layers. Spring Authentication was used to authenticate with LDAP. Additionally, the Spring LDAP template was used to access and update the LDAP repository.
  • JPA and Hibernate – a Java persistence architecture to map and interact with MySQL using Java JDBC drivers.

Development Environment

Development was performed using Spring STS and the Eclipse IDE with a Tomcat application server. A cloud-based development EC2 MySQL instance was used. Maven was used for dependency management and build support.

Git is the source repository we used for this internal development project. Github was used to host our repositories. Git worked extremely well considering that we have a distributed workforce, a trait nearly universally found in the enterprise. To execute a Maven package goal, we installed a Hudson server instance on an Amazon EC2 instance with a Hudson project configured. This goal compiles, builds, tests and produces a WAR file, which is then deployed to a test application server.

Server Side Implementation

Server side components are implemented using Java EE components and are deployed as a WAR file component to an application server. Application logic and data access to the timesheet system’s relational data store follow a layered application architecture.

Service/POJO/Data Access

Server side services are implemented as Spring framework service classes. They provide an API for POJO models to be created, retrieved, updated and deleted (CRUD). JPA is used as the persistence mechanism. Since this does not need to be “pluggable,” references to the JPA entity manager are done directly via Spring in the service.

For the sake of correctness, the EntityManager reference is arguably a DAO. If we anticipated a data source change, we would have implemented a contract/interfaced DAO for pluggability. We also used the Spring Data framework for some services that required more SQL queries. The agileness, some might call magic, of Spring Data’s ability to dynamically implement code is very agile.

RESTful JSON Endpoints

Service methods are accessed using a RESTful URL pattern and return JSON data payloads. This is accomplished using the open source framework khsSherpa. Endpoints are defined by creating Endpoint classes that are annotated with the khsSherpa framework annotations. Methods in the endpoint class can be annotated as with RESTful URL actions. The framework handles parameterization and serialization of object and arguments automatically.

LDAP Authentication

Employees are authenticated into the application against a Crowd LDAP user repository. This is accomplished using Spring Authentication frameworks and a LDAP template. The khsSherpa framework is integrated with Spring Authentication, and therefore only LDAP configuration context files are required.

If authenticated, a random token is returned and must be used by subsequent requests. The token is associated with a timeout and lifetime period.

Authenticated URLs

The JSON endpoint framework provides a token-based authentication mechanism. Authenticated RESTful URLs must be accessed with a valid token and User ID, which are stored in the request header. The khsSherpa framework automatically authenticates token and ID against a pluggable token manager. Non-authenticated public endpoints can also be defined. In the case of our time sheet application, only authenticated URL’s are required. The endpoint framework allows endpoints to be secured across the board, using a property file, or at a endpoint/class level.

Unit Testing

To test server side Service/DAO implementations, we chose to use JUnit. Also, since the endpoints are POJO-based, they can be tested without a server, using JUnit.

Client/Browser Side User Interface: 100% Javascript

Instead of defining dynamic HTML with a server side MVC, a client side MVC is used. The entire front end is constructed with JavaScript. Common frameworks are used to help with modularity and dependency management. This is an essential component, as this architecture needs to support a large application (not just a website) with widgets. And, by itself, JavaScript does not have the necessary structure to support modularity.

JavaScript elements are contained within the Java EE WAR component and can be defined in web content folders.

Modularity/Dependency Management

As mentioned above, JavaScript does not provide any kind of modularity or dependency management support. To to fill this need, the open source community developed the Require.js framework.

Traditionally, JavaScript frameworks are defined in source files and loaded using the src=”<javascript>” attribute. This becomes unwieldy when lots of JavaScript files and modules are involved, along with possible collisions of the JavaScript namespace and inefficiencies when loading a module multiple times. Also, since there is no kind of import mechanism for dependencies, the Require framework allows modules to be defined that validate dependent libraries of modules. This is a necessary modularity mechanism for large applications.

MVC Pattern

The application user interface is constructed using the Backbone.js JavaScript MVC framework. Backbone supports the separation of application navigation and logic from the View implementation. The same design patterns and techniques are applied in the same way that the server side MVC is applied to JSP, JSF, and template mechanisms. However, the key factor in all client side JavaScript is the providing of a rich and responsive user interface.

Our timesheet system’s user interface is comprised of many view.js files. Views in Backbone.js parlance are actually controllers. They obtain a collection of JSON objects, define event handlers for UI elements (such as buttons), and render an HTML template.

As an example, here’s a UI screenshot of weekly timesheets for a single employee:

Single Employee, Weekly Timesheets

This user interface is built using a Backbone View module, Collection module and HTML template. Collection modules retrieve and contain JSON model objects for the view.

HTML5 Role-based Access

Access to certain features of the timesheet application is determined by the authenticated user role. As mentioned, roles are identified by the LDAP Group that the user is a member of. When an HTML template is rendered, an HTML5 data-role tag attribute is defined. It references a JavaScript function that determines if the user has access to the specified role. The function calls a service side endpoint that returns valid roles for the user. Features and data for the user interface are contained with <div> tags, so this where the data-role is applied. Users with the supplied role can only see elements within the <div>.


Timesheet Reports are defined and formatted using the Eclipse BIRT report framework. BIRT reports were created using the report designer and deployed with the WAR. A user interface is created to accept report parameters, and an endpoint is defined that will consume those parameters and return a PDF. That PDF is produced by the BIRT reporting engine, which is embedded in the server side timesheet application WAR.

Below is an example of the Report Launch UI:

Case Study Image 7

Native Mobile Application

HTML5 allows you to write a single user interface that is responsive to multiple device screen resolutions. However, there are cases where a native app may be required in the enterprise. Our architecture supports native applications by consuming the same server side endpoints as the HTML5 client side application.

To validate this, we’ve also built a native iOS application. See the screenshots below:

Timesheet mobile screenshot2     Timesheet-mobile-screenshot


Our goal in building this application was to validate that robust enterprise applications can be built successfully using HTML5/JavaScript and related frameworks. That goal was proven to be viable.