The Fluid Loader

Motivating the Fluid Loader

Javascript development suffers, amongst other hazards, from considerable immaturity in the tool chain and packaging workflow. For example, here is the <head> material from one of the demonstration pages for the Fluid Inline Edit component:

<head>
  <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
  <title>Inline Edit Manual Test Page</title>
  <link rel="stylesheet" href="InlineEdit.css" type="text/css" media="screen" charset="utf-8" />
  <link href="fluid-components/css/jquery.tooltip.css" type="text/css" rel="stylesheet" media="all" />
        
  <script type="text/javascript" src="fluid-components/js/jquery/jquery-1.3.2.js"></script>
  <script type="text/javascript" src="fluid-components/js/jquery/jquery.keyboard-a11y.js"></script>
  <script type="text/javascript" src="fluid-components/js/jquery/jquery.tooltip.js"></script>
  <script type="text/javascript" src="fluid-components/js/jquery/jARIA.js"></script>
  <script type="text/javascript" src="fluid-components/js/fluid/Fluid.js"></script>
  <script type="text/javascript" src="fluid-components/js/fluid/InlineEdit.js"></script>
  <script type="text/javascript" src="tests/utils/DebugFocus.js"></script>

</head>

On this Page

To aid filesystem-based development, the "fluid-components" base package is typically checked out at a particular physical relative path to the working project, and all required files must be referenced at this path. This makes projects extremely fragile to being moved to different working environments, even by the same developer. In another working style, packages are referenced at "server-relative paths", for example "/fluid-components/js/jquery/jquery-1.3.1.js" - this at least allows the promise of portable paths between client-based and server-based environments, but places strong restrictions on deployment possibilities. In some client environments, such as Windows, this choice is not possible.

Goals for the Fluid Loader

Allow "logical" resolution of artifacts (by "package" or logical name) rather than physical file-based resolution
Allow working styles where files are developed in smaller physical units, but can be addressed during production via aggregated/minified versions
Automatically find and resolve dependencies (both JS and CSS) of required artefacts

Sample header using Fluid Loader

  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
    <title>Inline Edit Manual Test Page</title>
    <link rel="stylesheet" href="InlineEdit.css" type="text/css" media="screen" charset="utf-8" />
        
    <script type="../js/fluid-loader.js"></script>
  </head>
  <body>
    <script>
      fluid.loader.load("InlineEdit", "tooltip", "DebugFocus");
    </script>
  </body>

Note that in this example:

The only required physical dependency is the "fluid loader", residing in a single (small) file, and which can be easily copied into the deployment unit
"Physical" paths appear in only one location, and there only to set up "optional configuration". At runtime, the loader automatically determines its environment based on a further Javascript file found in the same directory as the loader.
Only "top-level" logical artefacts need to be named, and all further dependencies are located automatically (JQuery itself, accessibility plugins, and also the required CSS dependency of the InlineEdit/tooltip environment

Configuring the physical environment

The "fluid-loader.js" file, when invoked, looks for and loads another, user-supplied file named "fluid-loader-map.js" in the same directory, holding contents such as:

fluid.loader.registerConfig("filesystem", "../../../../fluid-components");
fluid.loader.registerConfig("server", "../../fluid-components");

Thus, relocating a project now needs to be done in only one position, and it is now transparent to changes between client and server environments.

Component status

The loader is currently at planning/conceptual stage, as is intended to enter development after the conclusion of the Fluid 0.6 release.