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>
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.