Service architecture

The first thing that should happen when your application is loaded is the registration of services' implementations so that they are then accessible from anywhere within the application. This section explains how to bootstrap the required and custom services at the app’s entry-point.

Once you’ve created your application in BladeRunner, you’ll have a number of files in the BladeRunner Application directory structure. If you look at the MyApp/default-aspect/index.html file, you’ll see it includes the CSS, the JavaScript and then, in a script tag, creates an App using code loaded from your project (e.g. myapp.App). This code is defined in App.js in your MyApp/default-aspect/src/myapp directory.

Caplin Libraries do not do anything when loaded, it’s up to the person writing the application to create and wire up the parts of the libraries and services you are using.

Standard Services

Services are used for two things: configuring the implementation of methods relied on by the Caplin Libraries (e.g. loading XML or HTML files), or allowing blades to provide services to other blades without creating a hard dependency between the blades. Services that many Caplin Libraries expect to be defined are:

  1. The XmlResourceService, which provides access to XML bundled by the XML Bundler. This is often used to load configuration files, e.g. for Grids or other caplin components.

  2. The HtmlResourceService, which allows code to get the contents of HTML files that have been bundled together. This is typically used to load templates for Presenter.

  3. The PermissionService, which allows you to find out what the currently logged-in user is allowed to do. This can be useful if you want to remove UI facilities for things the user is prohibited from doing.

  4. The AppService, which allows you to retrieve application property values, usually used to configure your application.

Because these services are needed by many parts of the Caplin Libraries, we provide default implementations for them.

Custom Services

There are a number of other services that the Caplin Libraries use, and you can also define your own and use those too. Here’s an example of using one of the other Caplin defined services.

Many applications need to know the user name of the currently logged in user. In the following example a message displayed when a user trades should include the user’s name.

The UserService interface is defined in the library as having a single function, getLoginName, which returns a string. Caplin Trader provides an implementation of this, but you can create your own implementation of the UserService and register it. Below is the simplest possible UserService, but it’s also possible to create one that gets the login name via an XHR to a protected servlet or uses a streaming connection.

mynamespace.MyUserService = function() {};
mynamespace.MyUserService.prototype = {
    getLoginName: function() {return "Bob";}

To use your new UserService you edit the aliases.xml file, in your default aspect’s resources directory. This will re-map the caplin.user-service alias to point to your implementation. Once you’ve done this, all your code (including the Caplin Trader libraries) will start using your implementation.

<aliases xmlns="">
    <alias name="caplin.user-service" class="mynamespace.MyUserService"/>

This service can then be used in the code that generates the message:

this.userService = caplin.core.ServiceRegistry.getService("caplin.user-service");
var buySellMessage = this.m_mTradeDetails['side'] == 'BUY' ? 'bought ' : 'sold ';
var sMessage = this.userService.getLoginName() + ' ' + buySellMessage + ' ' + this.m_mTradeDetails['amount'] + ' ' + this.m_mTradeDetails['dealtCurrency']
    + ' at the rate ' + this.m_mTradeDetails['rate'];

There are other services you may want to use, or for which you might want to provide custom implementations. For details on those, see the Available Services documentation.


To get log messages in the JavaScript console from Caplin Libraries, you create and register a ConsoleLogger. During initial development, you will most likely want to use the ConsoleLogger that we provide, but later on you may want to use the StoreLogger, or your own logger so that end users can see log messages for fault diagnosis.

The logging system uses services and the event hub underneath, but for basic usage, you can just use the methods on caplin.core.log.Log. You can get started with the ConsoleLogger with the following piece of code in your App initialisation:

caplin.core.log.Log.register(new caplin.core.log.ConsoleLogger());