Application structure

Apps consist of a number of bladesets and aspects. They conform to the Java Enterprise Edition 5 specification of a web-app, so you’re free to add your own servlets and filters to the WEB-INF/lib directory, and update the web.xml file appropriately. The servlets and filters that comprise the BladeRunnerJS server infrastructure are populated when an App is created.

Other JavaScript libraries can be added into the thirdparty-libraries directory. You can also create your own user libraries and add them to the libs directory. They will all be included into the JavaScript bundle file if they are referenced in your code.

BladeRunnerJS apps are delivered as J2EE WAR files. The specific settings for each environment are configured via JNDI. You can specify a database connection or even an environmental string to be used, in HTML. BladeRunnerJS filters replace known tokens with the value of your JNDI configured variable.

Typically, different Aspects will use different layout managers. A fully-fledged desktop browser aspect for example, might use a complex layout manager like Webcentric, with a mouse-oriented display, and many components and panels in view at the same time. Another aspect might use HTML, and embed single components for use on a mobile device. Aspects allow you to share blades between different web pages.

Users will request the entry page of the aspect (usually index.html) from the root of the aspect’s directory. The various bundlers scan the entry page, perform their dependency analysis and generate the appropriate bundles. Only the referenced blades are loaded, and blades from different bladesets may be included. Any assets common to the whole aspect are loaded from the src, test and resources directories of the aspect.

If you wish to create code (or use libraries) that are not compatible with the Caplin bundlers, simply place that code and other assets inside the unbundled-resources folder.

A bladeset is a collection of blades that share some common code. They can also share assets such as styles, HTML templates and images. This allows you to create logical groupings of blades that display information in a consistent way. For instance: you would use a bladeset to share the custom code for numerical formatting in a set of blades, or to house a common date-chooser configuration.

Each blade is a separate module, containing the code and resources for a single feature. For example: a form component, which receives, validates and submits data to the server. Largely, it consists of various JavaScript classes that contain business and presentation logic, plus some CSS and HTML that provide the view. It contains all the assets required to:

Blades can reference code in libraries, but cannot directly reference code in other blades. This isolation means blades can be moved, deleted, copied and changed without affecting other blades. All the assets are held under a single directory that conforms to the structure shown below, with any assets that are shared between blades being held at the bladeset level.

You supply common services to your blade via our service registry. Blades communicate with each other indirectly via the event hub.

All code must reside under the correct sub-directory e.g. all JavaScript code must be placed inside the src directory. Most of your app’s code consists of a (possibly large) number of blades. The code from those blades is automatically combined by the bundlers and returned to the browser.