How CT4 Fits Together

You might also find it helpful to read key concepts if you haven’t yet

A CT4 application is a single-page Application that loads all required JavaScript from the browser and initialises itself before the user can start interacting with it. It conforms to the standard BladeRunnerJS structure and conventions

Start the BRJS process

The BladeRunnerJS process starts an ApplicationServer that receives requests for your webapp. It pulls together all of your code and serves them in a few "bundle" files. You are free to split all your code into as many files and directories as you like, without the overhead of getting them all loaded into the browser. Just stick to the BladeRunnerJS structure and it takes care of itself.

Loading files on an F5

BladeRunnerJS works in two modes: "dev mode", where all assets for your app are loaded on-demand, as soon as you hit F5. You can add/remove and change dependencies for files, F5 is always your only build step for fast develop-refresh cycles. "prod mode" is where all assets are pre-bundled into one file, minified and gzipped at build time and inserted into a war for deployment onto J2EE servers.

In development mode, when the application index.html is being requested, BladeRunnerJS reads special tags that are included in the source page to work out which assets are required and in what configuration

<html>

<head>
    <@css.bundle theme="noir"@/>
    <@i18n.bundle@/>
    <@js.bundle dev-minifier="combined"@/>
</head>

<body>
    <script>
    new myApp.App();
    </script>
</body>

</html>

BladeRunnerJS notices those tags and searches the page for JavaScript as well as other configuration files. These seed files also require other JavaScript files and eventually it builds an in-memory map of all the JS files needed. BladeRunner does not load all the files in BladeRunnerJS libraries. You only include the code needed by the app.

BladeRunnerJS now uses the info gained during JavaScript loading to load CSS. CSS is loaded for libraries, the application and any specific CSS for each blade component. There are also special CSS overrides to help you with more awkward browsers or different CSS for locales. Internationalised strings for messages are also loaded at this stage. The special tags are replaced with links to the bundles. Below is what the page looks like when you do a "view source" in the browser.

<html>

<head>
   <link rel="stylesheet" href="../v/dev/css/common/bundle.css"/>
   <link rel="stylesheet" title="noir" href="../v/dev/css/noir/bundle.css"/>
   <script type="text/javascript" src="../v/dev/i18n/en_GB.js"></script>
   <script type='text/javascript' src='../v/dev/js/dev/combined/bundle.js'></script>
</head>

<body>
   <script>
   new myApp.App();
    </script>
</body>

</html>

Build the Layout Manager and Components

Once the index page is loaded, the app is initialised by the main application JavaScript code. It intialises services and registers them with the ServiceRegistry. These are typically central configuration information that components need, server connections such as a streaming connection to the Caplin Platform or layout services so that components can communicate changes that need to be made in the layout.

The application also bootstraps the layout manager which then loads components. Or it simply creates the components and puts them on the page if it is a simple app.

Webcentric

Webcentric is CaplinTrader’s library for providing rich GUI frameworks that allow the user to customise, save and manage the layout of components. It loads the user’s layout from the server, puts the layout on the screen and loads the components based on the configuration in the layout.

Presenter Components

We recommend using Presenter to build components. It creates a view model in JavaScript and uses Knockout.js to bind HTML and the JavaScript. View models in pure JavaScript allow easier testing of components and cleaner code.

Where Next?