This section is critical to understanding the way that your application should be organised in order to have a seamless development experience with BladeRunnerJS, while at the same time achieving a modular 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.
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.
- Run the feature in a containing App.
- Run the feature in a stand-alone web-page known as a workbench.
- Test any code that is part of the blade (unit and acceptance tests).
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.