Overview

##xTuple Web-Mobile client

The xTuple web client is an alternative to the traditional Qt C++ based desktop client used for Postbooks opensource and commercial software. It is designed so that both the desktop client and web client can work on the same database simultaneously. The web client is built using JavaScript in all layers including the database, the web service and application layers. This platform is designed to be fully extensible and customizable without changing any core code. Below is a short overview of the major technologies used in the xTuple web-mobile stack:

##Enyo

Enyo is a framework for building web client applications that work on all devices and form factors. The HTML presentation is generated entirely by the client. The xTuple implementation of Enyo is designed as an object model hierarchy so that components are reusable as the application is expanded and customized. We've effectively created a set of building blocks that can be quickly mixed and matched to create new modules and applications. The framework of user interface objects is called enyo-x. The Picker Widget is an example of an enyo-x object. Note it is just over 300 lines of code. Less code here means a more flexible and managable application framework.

##Backbone

Backbone is a client side model system written in JavaScript. While Enyo lets us define the presentation bits you see and touch, Backbone provides a layer where we handle the business logic behind the scenes like "The amount attribute must be a number" or "When the status changes to 'Completed' the complete date should be set to today's date." More importantly, it provides a simple and consistent interface for fetching, editing and saving data through the datasource. Again, we have created our own version of Backbone called Backbone-x to handle our specific design requirements, along with a library of core models to support Postbooks. The Contact file is a good example of a set of these core business objects. Note how little code there is for each model. This is because most of the definition, including privilege and data structure, is derived [reflectively](http://en.wikipedia.org/wiki/Reflection_(computer_programming%29) from the ORM system described below.

Backbone-x actually builds on another Backbone based project, Backbone-relational, that sits between Backbone and Backbone-x. Backbone-relational handles the additional complexity introduced when managing multiple related sets of records as a single object hiearchy. Sales Order is an example of a complex object that has a header, one-to-many comments, and one-to-many line items. When editing a line item, the entire order object will be marked as "dirty" so that the order can be saved in a single commit that updates all line items or comments that have changed in a single unit of work.

##NodeJS

V8 is Google's JavaScript engine that is used to power its Chrome browser. NodeJS is a platform for building network applications using JavaScript that runs on the V8 engine and is specifically designed for the modern cloud environment. We use it as the basis for our web service we call the datasource. The datasource's main jobs are to:

• Handle authentication following Oauth2 protocol.
• Serve up the application code
• Receive and respond to data requests.

Data requests can be handled by either REST conventions or a Web Sockets connection. The [REST implementation] (https://github.com/xtuple/xtuple/wiki/xTuple's-REST-API) uses GET for querying lists or retrieving a single object, POST for creating new data objects and executing database side procedures, PATCH to perform updates per RFC6902, and DELETE for deleting objects.

It is worth noting that except for the login screen the datasource does not serve up HTML or any other presentation content. That is all accomplished by the client code described above.

##PLV8 and PostgreSQL

PostgreSQL was written first and foremost as an object relational database, meaning that it combines features of object oriented and relational data models. This means Properly written SQL queries can output results as object hierchies natively. PLV8 is an integration of Google's V8 JavaScript engine with the PostgreSQL database that allows us to manage business logic using JavaScript while maintaining ACID compliance for transactional processes. It also provides a declarative mechanism to enforce data relationships, privileges and other server side business logic while eliminating datatype conversion (a.k.a. impedance mismatch) problems between the client and the server. This allows us to literally drop a JavaScript object directly from the cilent to the database so it can process the object directly with no intermediate translation. We have leveraged these technologies to build an embedded Object Relational Map (ORM) system for PostgreSQL to process this data to and from the database tables. The ORM effectively allows PostgreSQL to "speak the language" of JavaScript which is JavaScript Object Notation (JSON). The ORM maps themselves are in JSON. You can see ORM map examples in our code base here and you can see examples of javascript doing the heavy lifting on reads and writes here.

##Modular Design

The base client application is designed in such a way that almost nothing is in it by default except User Accounts. All end user functionaly is added by Extensions. However, the base application includes a set of core data models and an expanding set of standard business objects that can be used by extensions to build useful modules. Over time, all the business objects available in the Postbooks desktop application will be mirrored in the web client.

The bottom box shows "core" objects that may be directly referenced by any other object. The middle box contains more functionally specific business objects that are generally independent from one another and except for the cases of objects that are direct children of a parent (i.e. Sales Order is a child of Customer) are not directly related to one another.

The top box shows the standard extensions in Postbooks. Extensions can assemble the various core and business objects together to build a module that is a collection of objects usually relevant to a particular role a user is required to perform. They also usually create relationships between objects, such as adding a one-to-many relationship between Opportunities and Quotes. Access to Extensions are granted at the user level so that if a user does not have access to an extension not only are the menu items removed from the application, but so are the relationships. So, for example, if a user has access to the CRM extension, but not Sales, then that user will not see the relationships between Opportunities and Quotes. This provides a simple mechanism for administrators to hide the overall complexity of our enterprise application from users who have no need to see it, while at the same time allowing users to have a fully integrated experience between modules when they are granted appropriate access.

If you are not satisfied with xTuple's extension design, you can easily mix and match business objects to create your own extension. Extensions are also not limited to the pre-existing set of core and business objects. New business objects can be built and integrated with existing ones. To get started on the basics of building your own extension please review the tutorial.