Loading
Wins
- Explicit control over package configuration and load conditions.
- Single-page optimized with live patching without flushing data.
- No module boilerplate in source code. No cyclic dependencies.
- Fully-integrated metadata shared across app, tools, and CLI.
- Full reflection data; all types, methods, attributes know load path.
Contents
Concepts
Cookbook
- Show The Boot Log On Launch
- Log At A Detailed Level During Boot
- Log To The Browser Console
- Pause After Loading/Before Starting
- Disable URL Argument Parsing
- Load Unminified Code
- Reflect on Load Path
Loader Activation
Loader Framing
Loader Stages
- Prelaunch
- Configuring
- Expanding
- Import (Phase One)
- Import (Paused)
- Import (Phase Two)
- Paused
- Activating
- Initializing
- Rendering
- Liftoff
- Stopped
Loader Profiles
Loader Packages
- Package Files
<package/>
Tags<config/>
Tags<script/>
Tags<property/>
Tags<resource/>
Tags<echo/>
Tags- Package Examples
Virtual Paths
Conditional Loading
Loader Screens
Loader Configuration
Loader Integration
Code
Concepts
TIBET applications launch and load via the TIBET Loader, a powerful, configuration-driven resource loader capable of loading components from the file system (including Electron), or any HTTP-compliant server, including HTTP-aware DBMS's like CouchDB.
TIBET loading occurs in a sequence which allows you to integrate login-triggered loading, visualize load progress, pause after load, track load paths, and much more.
The TIBET Loader reads and processes package definitions to load resources. This approach allows you to define resource packages explicitly and apply conditions to each resource. Resources can load conditionally based on browser, user language, user role, etc. and do so during application launch or dynamically at runtime. You are in control.

Cookbook
Below are a few common things you may want to try out:
Show The Boot Log On Launch
Set boot.show_log
to true:
http://127.0.0.1:1407#?boot.show_log

By default the boot log will display messages output at the TP.SYSTEM
level, a
level reserved for system messages from TIBET.
Log At A Detailed Level During Boot
Set boot.level
to a specific value from the list:
TP.ALL = 'ALL';
TP.TRACE = 'TRACE';
TP.DEBUG = 'DEBUG';
TP.INFO = 'INFO';
TP.WARN = 'WARN';
TP.ERROR = 'ERROR';
TP.SEVERE = 'SEVERE';
TP.FATAL = 'FATAL';
TP.SYSTEM = 'SYSTEM';
TP.OFF = 'OFF';
Note that you can use uppercase or lowercase level names:
http://127.0.0.1:1407#?boot.level=trace

When logging at TP.TRACE
level the boot log will show you each file and inline
script it loads, in order.
Log To The Browser Console
Set boot.console_log
to true, or use it on the URL:
http://127.0.0.1:1407#?boot.console_log

Console-directed logging can be extremely useful if you've modified the boot screens or made other changes to the default TIBET startup infrastructure.
Pause After Loading/Before Starting
Set boot.pause
to true, or use it on the URL:
http://127.0.0.1:1407#?boot.pause

Boot with your debugger closed so you don't wait too long, then open it, set your breakpoints, get yourself set, and then yes, just click the play/pause button :).
Disable URL Argument Parsing
Set boot.nourlargs
to true via tibet config
or TP.sys.launch
:
Via tibet config
on the command line:
$ tibet config boot.nourlargs=true
Via TP.sys.launch
in your index.html
file:
...
<body onload="init()">
...
<script src="./node_modules/tibet/lib/src/tibet_loader.min.js"></script>
<script>
//<![CDATA[
function init() {
TP.boot.launch({ boot: { nourlargs: true }});
}
//]]>
</script>
...
</body>
...
Load Unminified Code
Set boot.minified
to false (with a development profile):
http://127.0.0.1:1407#?boot.minified=false&boot.profile=development
Reflect on Load Path
Query any TIBET type, method, etc. via the TP.objectGetLoadPath
primitive:
TP.objectGetLoadPath(TP.core.Hash);
"~lib_src/tibet/kernel/TIBETCollections.js"
Loader Activation
TIBET applications load in response to invoking the TP.boot.launch
method
provided by the tibet_loader.js
boot script (often in minified form).
For example, here's the relevant portion of the default index.html
file:
...
<body onload="init()">
...
<script src="./node_modules/tibet/lib/src/tibet_loader.min.js"></script>
<script>
//<![CDATA[
function init() {
TP.boot.launch();
}
//]]>
</script>
...
</body>
...
Each of TIBET's default application templates provides an index.html
file
containing logic similar to what you see here. You include the tibet_loader.js
script or a minified version of it and trigger TP.boot.launch
once the page
has loaded.
Load State
Once the TP.boot.launch
sequence is triggered TIBET will begin loading
resources. TIBET library resources load during phase one, your application
resources load during phase two. During this process TIBET sets variables to
track load status:
TP.sys.hasKernel();
TP.sys.hasLoaded();
TP.sys.hasInitialized();
TP.sys.hasStarted();
The TP.sys.hasKernel
setting is defined by the last file of the kernel
package, TIBETFinalization.js
. This flag lets certain aspects of the system
switch from "boot primitives" to "kernel primitives" which have more error
handling.
The hasLoaded
, hasInitialized
and hasStarted
flags let you know that TIBET
has finished loading all resources, that it has initialized all types with an
initialize
method, and that it has triggered and completed the application
startup sequence.
Startup Sequence
Once the system has loaded a sequence of methods and signals are invoked which provide you with multiple hook points into system activation. The rough sequence is outlined in the list below which takes things from start to finish:
TP.boot.launch() // Trigger the loader to begin running.
TP.sys.hasKernel(true); // End of `TIBETFinalization.js` load.
TP.sys.hasLoaded(true); // End of all resources loading.
TP.boot.main() // Invoked after all resources are loaded.
TP.boot.$activate() // Installs onbeforeunload and similar hooks.
TP.sys.activate() // Triggers application startup sequence.
// Hookable signals prior to type and core initialization.
TP.signal('TP.sys', 'AppWillInitialize');
TP.signal('TP.sys', 'AppInitialize');
Type Initialization // Invokes `initialize` on implementing types.
Core Initialization // Series of initialization functions.
'Initializing root canvas...'
'Initializing type proxies...'
'Initializing namespace support...'
'Initializing default locale...'
TP.sys.hasInitialized(true);
// Hookable signal for post-initialization processing. This is
// a good place for things like registering strings for locales
// etc. so they're available prior to UI loading.
TP.signal('TP.sys', 'AppDidInitialize');
TP.sys.loadUIRoot(); // Begins the UI loading/rendering cycle.
// Hookable signals prior to application start invocation...
// but after the UI has been loaded so initial screen DOM is
// accessible.
TP.signal('TP.sys', 'AppWillStart');
TP.signal('TP.sys', 'AppStart');
// Default handler for AppStart triggers...
TP.sys.getApplication().handleAppStart()
// Normally not overridden, better to use signal handlers or
// finalizeGUI.
TP.sys.getApplication().start(aSignal);
// Override this as needed, but invoke TP.boot.showUIRoot()
// when done or better yet `return this.callNextMethod()` :).
TP.sys.getApplication().finalizeGUI();
// Hookable signal for post-startup processing. App is running.
TP.signal('TP.sys', 'AppDidStart');
Loader Framing
Like most web applications, TIBET applications start out from index.html
. The
TIBET difference is that you rarely edit this file since it defines
framing to isolate code and data for single-page applications and reduce reload
overhead.
The index.html
file
Here's the relevant UI framing from the default index.html
file:
...
<body onload="init()">
...
<iframe id="UIROOT" frameborder="0"
src="./TIBET-INF/boot/xhtml/blank.xhtml"></iframe>
<iframe id="UIBOOT" frameborder="0"
src="./TIBET-INF/boot/xhtml/UIBOOT.xhtml"></iframe>
...
</body>
...
Here we can see TIBET's standard UIROOT
and UIBOOT
iframe elements.
During loading your application typically displays content in the UIBOOT
<iframe>
which includes a variety of built-in boot progress displays. Once your
application code has loaded your project's root page loads and the UIROOT
<iframe>
becomes active.
The Code Frame
We mentioned UIBOOT
and UIROOT
, the two <iframe>
elements TIBET uses to
manage the user interface during startup and application operation.
There's one other frame (or more accurately Window) we haven't talked about:
top
.
In TIBET applications top
is what we call "the code frame". During the loading
phase your application code is loaded in top
along with any shared data.
The content of the code frame (top
) is never altered for UI purposes, your UI
remains isolated in UIROOT
, allowing you to completely reload the UI without
impacting any shared code or data. Your code and data persist regardless of UI
changes.
Loader Stages
The TIBET Loader actually operates by iterating through a sequence of stages, from a prelaunch stage which verifies the boot environment through the final stage where your application class has been triggered and is now running.
Here's the complete list of stages, in order, along with their general role:
{
prelaunch: 'Verifying environment...',
configuring: 'Reading configuration...',
expanding: 'Processing boot manifest...',
import_phase_one: 'Importing phase-one (static/library) components...',
import_paused: 'Waiting to start phase-two import...',
import_phase_two: 'Importing phase-two (dynamic/application) components...',
paused: 'Proceed when ready.',
activating: 'Activating application...',
initializing: 'Initializing loaded components...',
rendering: 'Rendering application UI...',
liftoff: 'Application running.'
}
Prelaunch
The prelaunch
stage verifies the current browser environment is supported.
Verification involves a combination of feature detection and browser version
checks. If the application cannot be run the launch is halted and an
error message is displayed.
Configuring
TIBET is an integrated system and the Loader is no exception.
Once the environment has been verified the Loader loads and leverages TIBET
Configuration data. The configuring
stage handles
loading configuration data, checking launch options, parsing url arguments, and
ensuring the system is configured.
Expanding
Loader profiles are essentially file names which point to TIBET package files
and configurations within those packages. During the expanding
phase the
Loader reads these files and expands them into a flat manifest suitable for
loading.
Production profiles normally reference a flat manifest to minimize overhead.
Import (Phase One)
The TIBET library operates in terms of two logical packages: lib and app.
In large-scale application environments, particularly those where a number of applications are being developed and deployed, it's more efficient to have a common and cacheable shared library package and separate application packages.
TIBET recognizes the value of separating relatively static and potentially large
library code from more dynamic and potentially smaller application-specific
packages and uses import_phase_one
to load static/shared library code.
While in this phase the configuration parameter boot.phaseone
is true.
Import (Paused)
Perception is 9/10ths of reality and perceived performance is a key perception to manage for large applications which might otherwise seem slow to load.
One way of managing the perception of performance that's particularly useful for applications that require a login is to load static/shared library code early but only load application-specific code once a successful login has been confirmed.
The import_paused
phase is a pause state specific to scenarios where the
application wants to load shared code early, perhaps from the HTML5 cache, and
only load the remaining code once a proper response from the server is received.
Import (Phase Two)
The import_phase_two
stage is typically used to load application-specific
resources which might change more frequently than the library code they rely
on.
For example, as a TIBET customer your application code will be changing daily as you develop, but you may only update your TIBET library weekly, or monthly, to get the latest stable release of library code.
While in this phase the configuration parameter boot.phase_two
is true.
Paused
Once all application code has finished loading the Loader will check the
boot.pause
configuration flag. If that flag is set the load sequence will
pause at this point to allow you to set breakpoints etc. before proceeding. That
can be very useful in browsers where having the debugger open during loading can
cause dramatically slower load times.
Click the default boot UI's "play/pause" icon to complete the startup sequence.
Activating
The activating
phase configures onunload hooks to ensure the user is prompted
before unloading all the code we just loaded, and then calls TP.sys.activate
,
the TIBET library's startup routine.
At this point control actually moves from the Loader into the TIBET library.
Initializing
TIBET is a heavily object-oriented library with hundreds of types. Before
triggering your application class to start()
all types with an initialize
method have that method run so they can do any post-loading/pre-start
initialization required.
Rendering
The rendering
phase is responsible for getting your application's UI ready for
use.
To render your application UI on startup TIBET leverages the values of two
configuration variables: project.rootpage
and project.homepage
.
The Root Page
The first configuration setting, project.rootpage
, defines the URL to load
into UIROOT
once all code has loaded. This value defaults to UIROOT.xhtml
, a
file whose content is simple, but indicative of perhaps TIBET's most striking
difference from most libraries:
...
<body>
<tibet:root/>
</body>
...
Not much there, just a single custom tag: <tibet:root/>
; what we call the "root tag". As we'll
see there's a lot of power in that tag and the TIBET Tag
System that supports it.
The Home Page
We mentioned there were two configuration variables driving your UI on startup.
The second of those values, project.homepage
, is used by <tibet:root/>
.
The <tibet:root/>
tag's role is to decide which home page to load and
whether to load it with or without TIBET's browser-based IDE, the
Lama™.
If lama.enabled
is true the Lama will load and your home page will be
rendered by the Lama, otherwise your home page loads directly into UIROOT
.
Note that the Lama itself might not be visible (by default it is hidden but can
be triggered if lama.show_toggle
is true). The Lama can also be shown
immediately on launch by setting boot.show_ide
to true.
By default project.homepage
resolves to a standard file, home.xhtml
, in your
application's TIBET-INF/boot/xhtml
directory.
If you're starting to suspect home.xhtml
contains more custom tags you're
right. The default version contains what we call the "app tag", a custom tag
which represents your application in reusable, easy-to-reference markup.
...
<body>
<demo:app/>
</body>
...
The implication of organizing your application around an "app tag" is that all TIBET applications are inherently reusable and composable.
We can take our <demo:app/>
tag and use it anywhere, not just as a standalone
application but as a component in a larger-scale application.
Further, having an application tag implies that there's little reason to alter
home.xhtml
. That file isn't responsible for your application UI, your
application tag is.
Liftoff
This is the final stage, which performs no processing but is simply a way of signifying to other system components that the application has started.
This phase is set by the TIBET library once the UI has fully loaded and the
application has finished running its start()
method. For more on the library
startup sequence see the documentation for the TP.core.Application
type.
Stopped
There's one other stage the loader can find itself in…which hopefully you'll avoid :)
stopped: 'Boot halted.'
The stopped
stage is set when a fatal error occurs during booting.
There are two common ways a fatal error can occur. One is that the error is
logged at the FATAL
level, and the other is that boot.fatalistic
is true and
an error in a library phase (activating, initializing, rendering) is logged.
Loader Profiles
When the Loader starts it relies on configuration settings to help it determine
what to load and how to load it. The most important of these Loader-centric
configuration settings are the boot.profile
and boot.config
values.
boot.profile
The boot.profile
setting tells the Loader which TIBET package file to read.
In the example below we're telling the Loader to boot the development
profile:
http://127.0.0.1:1407/#?boot.profile=development
If you've read TIBET Configuration you should recognize the URL above as one whose fragment (hash) contains URL-based configuration parameters read by the Loader.
Loader boot.profile
values must resolve to a full path but TIBET provides a
lot of defaulting to keep things simple. As a result most boot.profile
values
are simple file names without directory or extension information.
By default TIBET packages are found in a directory defined as ~app_cfg
,
which defaults to the TIBET-INF/cfg
directory in your application's
root directory. Load packages must be XML so we can use a .xml
extension to arrive at ~app_cfg/development.xml
.
This value defaults to main
and hence ~app_cfg/main.xml
.
boot.config
Along with the boot.profile
the Loader needs a value for boot.config
which
defines the config ID in the package to load, literally a config element ID.
Your boot.config
can default based on content in the package or specified
directly or indirectly in your TIBET configuration.
You can define boot.config
explicitly using a second boot parameter (or in
your tibet.json file for persistent settings):
http://127.0.0.1:1407/#?boot.profile=development&boot.config=developer
For simplicity you can also specify the boot.config
value as part of your
boot.profile
by adding a '@' as follows:
http://127.0.0.1:1407/#?boot.profile=development@developer
This latter form is far more common since it's a bit cleaner and easier to use.
The boot.config
value defaults to the value of the default
attribute on the
boot.profile
document's root <package/>
element.
Loader Packages
Package Files
A package file is an XML file containing at least one root <package/>
tag and
one child <config/>
tag used to define load scripts, resources, and
properties.
Here's the default package used by most TIBET applications:
<?xml version="1.0"?>
<package xmlns="http://www.technicalpursuit.com/1999/tibet"
id="demo" default="base" basedir="~app_cfg">
<config id="base">
<package src="tibet.xml" config="base"/>
<package src="{{appname}}.xml" config="base"/>
</config>
<config id="full">
<package src="tibet.xml" config="full"/>
<package src="{{appname}}.xml" config="full"/>
</config>
<config id="developer">
<package src="tibet.xml" config="developer"/>
<package src="{{appname}}.xml" config="developer"/>
</config>
<config id="contributor">
<package src="tibet.xml" config="contributor"/>
<package src="{{appname}}.xml" config="developer"/>
</config>
<config id="test">
<config ref="developer"/>
<package src="{{appname}}.xml" config="tests"/>
</config>
</package>
As you can see from this package file the lib vs. app pattern is very clear. The
tibet.xml
packages provide configurations of library code while the
{{appname}}.xml
packages provide configurations of your application code.
<package/>
Tags
A root <package/>
tag provides information about the package such as the
package name, the default config ID to load in the absence of a boot.config
value, and the base directory from which to compute any relative paths.
<package xmlns="http://www.technicalpursuit.com/1999/tibet"
id="demo" default="base" basedir="~app_cfg">
Looking back at the main.xml
package we just listed the package name is
demo
and the default config ID is base
. The basedir for path
computation is ~app_cfg
.
As shown in the main
package, <package/>
tags can also be used within a
<config/>
tag to point to an external package. This allows you to create
nested packages and easily reference external component configurations.
The following entry refers to the {{appname}}.xml
package's tests
config:
<package src="{{appname}}.xml" config="tests"/>
<config/>
Tags
A TIBET <config/>
tag defines a specific set of resources to load and any
properties which should be defined during the configuring
stage of the load
process.
The Loader always works from the boot.config
referenced <config/>
tag down,
recursively expanding all its contained <config/>
and <package/>
components until it has a flattened list of load resources, properties, and
instructions. Circular references are discarded and duplicates are removed so
you get a single, consistently ordered list.
Let's look at a few examples pulled from the default {{appname}}.xml
package:
...
<config id="base" if="boot.phase_two">
<config ref="app_img"/>
</config>
<config id="app_img">
<script src="~app_src/APP.demo.js" />
<script src="~app_src/APP.demo.Application.js" />
<script src="~app_tags/APP.demo.app/APP.demo.app.js" />
</config>
...
The three <config/>
tags in our sample provide a good look at typical
usage.
The first <config/>
tag has an id
of base
, which is the typical default
for most packages. In the absence of other information you can assume this
config will be the one loaded. Note that it loads during phase two (the app
phase).
The second <config/>
is actually nested inside our base
config and has no
id
attribute. Instead it has a ref
attribute which points to the third
config tag, literally including it by reference. This approach is common since
it makes it easy to compose large configurations from smaller modules.
The third <config/>
is identified as app_img
and contains three <script/>
elements which reference source code residing in the application's source
and tags directories (referenced here as ~app_src
and ~app_tags
).
<script/>
Tags
Loader <script/>
tags are similar to typical script tags with the exception
that they are never processed in an HTML context. As a result they serve only as
instructions for the Loader with respect to the resource to load.
<script src="~app_src/APP.demo.js" />
Most script tag entries point directly to a source file via their src
attribute, but the Loader also supports inline source in a script tag. Note the
use of a CDATA block here; these are XML files, not HTML files, so CDATA blocks
avoid problems with embedded entities:
<script>
<![CDATA[
TP.extern.JsDiff = JsDiff;
]]>
</script>
You can leverage inline script to handle potentially complex loading scenarios. In the following example we put a CommonJS module wrapper around an external module used by the TIBET test harness to load it properly:
<config id="gui">
<script>
<![CDATA[
if (TP.sys.cfg('boot.context') !== 'phantomjs') {
(function() {
]]>
</script>
<config ref="syn"/>
<script>
<![CDATA[
}());
}
]]>
</script>
<script src="automation/TPGUIDriver.js" />
</config>
<property/>
Tags
The <property/>
tag gives you a way of setting TIBET
Configuration values specific to a <config/>
. A common
place for this is in developer profiles where you may want to set more verbose
logging or debugging flags.
Here's a canonical <config/>
named properties
which loads during phase one
and which alters several flags useful for development:
<config id="properties" if="boot.phaseone">
<property id="tibet.lama" value="true"/>
<property id="debug.use_debugger" value="true"/>
<property id="log.bootcfg" value="true"/>
<property id="log.bootenv" value="true"/>
<property id="log.level" value="DEBUG"/>
<property id="log.stack" value="true"/>
</config>
The Loader processes property tags as part of the loading process so its best to configure them to be run in phase one and as the first part of a larger config:
<config id="base">
<config ref="properties"/>
<package src="standard.xml" config="base"/>
</config>
<resource/>
Tags
A <resource/>
tag lets you specify templates, style sheets, or other resources
which might otherwise be missed by the TIBET packaging logic.
Under normal circumstances a templated tag will assume a matching xhtml
and
css
file but in some cases you may find it necessary to tell the system about
additional resources. When more control is needed use a resource tag.
You can reference a block of resources using a directory reference rather than
an explicit file name. For example, here's the standard resources
target from
a typical application configuration file:
<config id="resources">
<!-- put non-bundle resource entries here -->
<resource href="~app/styles"/>
</config>
To refer to specific resources simply use the href
attribute of the resource
tag to point to the target asset.
<echo/>
Tags
An <echo/>
tag gives you a simple way to inject your own messages into the
log:
<echo message="hi there"/>
You can use the level
attribute to set a TIBET log level for the message.
Package Examples
For more examples of usage see the package files in an application's TIBET-INF/cfg directory or in the TIBET library's lib/cfg directory.
Virtual Paths
We've seen/used configuration values beginning with a ~
(tilde) in a few
places. These references are what TIBET calls "virtual URIs", paths whose
concrete value is resolved at runtime by looking at the launch root and other
startup data.
A virtual path of ~app_src
may resolve to file:/c://some_source_directory
on
Windows, to file:///some_src_dir
on Unix, and https://myhost.com/src
when
the application launches via https. That's the value of a virtual URI, it gives
you a way to point to a file without a hard-coded path you may have to update
later.
To see the actual location referenced by a virtual path replace the ~
with
path.
on the tibet config
command line or in the TP.sys.cfg()
call. It may
be necessary to recursively perform this operation to get full resolution:
$ tibet config path.lib_boot
{app_directory}/node_modules/tibet/TIBET-INF/boot
Conditional Loading
For every tag it comes across the Loader checks for if
and unless
attributes. If the tag has either one, or both, the Loader will check the
configuration value referenced to determine whether the tag is relevant.
For if
tags the value must resolve to true for the tag to be used.
For unless
tags the value must resolve to false for the tag to be used.
Tags containing both conditions must obviously pass both tests.
Value checking for if
and unless
considers the results of the TP.sys.isUA
call (for browser checks), the TP.sys.env
call (for "environment" settings),
and the TP.sys.cfg
call (for configuration settings).
A common test is a phase check to ensure a certain config or script is only loaded during a particular phase:
<config id="base" if="boot.phase_two">
<config ref="app_img"/>
</config>
Another common case is checking for boot.unminified to constrain loading:
<script src="~lib_deps/bluebird-tpi.min.js"
unless="boot.unminified" no-minify="true" no-lint="true"/>
Note the no-minify
attribute used by tibet rollup
and the no-lint
attribute used by the tibet lint
command here; both are good examples of
leveraging the Loader's package descriptions for more than loading.
Loader Screens
The TIBET Loader doesn't just load code, it also provides a variety of ways to get visual feedback during the boot process. For example, on startup TIBET will display a default load screen and interactive progress bar during loading:

The Boot Page
What you see while you boot is controlled by a variety of factors but the most
important is simply the file which is placed in the UIBOOT
frame.
The default UIBOOT
page is TIBET-INF/boot/xhtml/UIBOOT.xhtml
. This value
is set in your project's index.html
file as you may recall. Changing it to
point to any other page is a simple way to change your application's boot
screen.
Boot Page CSS
Rather than altering the page you could simply manipulate the CSS which affects
it. Your project's app.css
file, typically found in styles/app.css
, is
loaded in your UIBOOT.xhtml
, UIROOT.xhtml
, and home.xhtml
files for this
reason.
The UIBOOT.xhtml
file contains a number of elements whose id
values begin
with BOOT-
giving you an easy handle to most of them.
For example, you can turn off display of everything but the standard Loader
progress bar using the following CSS in your project's app.css
file:
#BOOT-IMAGE, #BOOT-SPLASH, #BOOT-HEAD, #BOOT-SUBHEAD {
display: none;
}

Obviously you can use this approach to change images, alter colors, fonts, etc. to meet the needs of your project.
Missing Boot UI
The boot parameters which define IDs for UI elements help the loader find those
elements in the UIBOOT
frame. If the elements aren't found the Loader simply
continues. This allows the Loader to run regardless of how you decide to
manipulate the UI page.
As a test you can "turn off" a lot of the boot UI interactions by altering the ID the Loader is looking for, setting it to something that can't be found.
http://127.0.0.1:1407#?boot.uiboot=MISSING
In this latter case you might want to combine that flag with some CSS alterations so your users don't see the prelaunch phase display. The key point is you have complete control over the boot UI.
Loader Configuration
The Loader both installs and leverages the TIBET
Configuration subsystem. During startup the Loader relies
heavily on configuration values with a boot
prefix.
Here's a current list of boot-prefixed configuration values:
{
"boot.console_log": false,
"boot.context": "nodejs",
"boot.defer": true,
"boot.delta_threshold": 50,
"boot.error_max": 20,
"boot.fatalistic": false,
"boot.karma_offset": "../../../../..",
"boot.karma_root": "/base",
"boot.level": "INFO",
"boot.libcomp": "script",
"boot.loader_offset": "../../..",
"boot.moz_xpcom": false,
"boot.no_tibet_file": false,
"boot.no_url_args": false,
"boot.parallel": false,
"boot.pause": false,
"boot.pause_on_error": false,
"boot.phantom_offset": "../../..",
"boot.reporter": "console",
"boot.rootcomp": "tibet_dir",
"boot.show_ide": false,
"boot.show_log": false,
"boot.stop_onerror": false,
"boot.supported_browsers": {"ie":[{"major":11}],"chrome":[{"major":39}],"firefox":[{"major":34}],"safari":[{"major":7}]},
"boot.supported_contexts": ["browser","electron","phantomjs"],
"boot.teamtibet": false,
"boot.tibet_dir": "node_modules",
"boot.tibet_file": "tibet.json",
"boot.tibet_inf": "TIBET-INF",
"boot.tibet_lib": "tibet",
"boot.tibet_loader": "tibet_loader",
"boot.tibet_pub": "public",
"boot.toggle_key": "TP.sig.DOM_Alt_Up_Up",
"boot.two_phase": true,
"boot.uiboot": "UIBOOT",
"boot.uicommand": "BOOT-COMMAND",
"boot.uiconsole": "BOOT-CONSOLE",
"boot.uihead": "BOOT-HEAD",
"boot.uiimage": "BOOT-IMAGE",
"boot.uiinput": "BOOT-INPUT",
"boot.uilog": "BOOT-LOG",
"boot.uipercent": "BOOT-PERCENT",
"boot.uiprogress": "BOOT-PROGRESS",
"boot.uisplash": "BOOT-SPLASH",
"boot.uisubhead": "BOOT-SUBHEAD",
"boot.unminified": false,
"boot.unminified_lib": false,
"boot.unresourced": false,
"boot.unsupported": false,
"boot.use_login": false
}
Documentation for the individual flags is currently sparse, but you can get a
decent idea of how each flag is used by looking at the content of
~lib_boot/tibet_cfg.js
.
Loader Integration
One final thing to be aware of is that the package files used by the Loader are also used by the TIBET CLI and the TIBET Lama.
For example, there's a <config/>
used to build the Loader itself which is used
by the tibet rollup
command we use within the library:
<config id="loader">
<script src="~lib_src/tibet/kernel/copyright.js" no-minify="true"/>
<script src="~lib_src/tibet/boot/tibet_pre.js" />
<script src="~lib_src/tibet/boot/tibet_cfg.js" />
<script src="~lib_src/tibet/boot/tibet_base.js" />
<script src="~lib_src/tibet/boot/tibet_post.js" />
</config>
Examples of commands which use package file information include lint
, test
,
package
, resources
, and rollup
. These commands are able to focus on the
specific files your application uses rather than scanning or relying on ignore
patterns.
Attribute values are also relevant. For example, the rollup
command makes use
of the no-minify
attribute on the copyright.js
entry to ensure that the
copyright comment isn't stripped out of the rolled up version(s) of the
tibet_loader.js
script.
By leveraging an external manifest-style package and config format all of TIBET can share Loader metadata and augment it as needed.
TIBET's runtime client library can tell you which file loaded every single type, method, and attribute in the system thanks to Loader integration. Using this information the Lama can edit a method, template, or other component in context.
These are just a few examples of the value of having consistent, easily managed descriptions of your application resources and configurations.
Code
The TIBET loader code is found in ~lib/src/tibet/boot
. Additional components
expected by the Loader are found in projects under the TIBET-INF
directory.