Dojo Build System, your own build experience
Dojo is not the most popular JavaScript framework, despite all its strength and positive qualities. Information that I want to convey to the reader today is required for absolutely every project built using this technology.
And we will talk about the assembly system.
The community offers us a ready-made optimized release, intended for placement on the server and use in web applications. By connecting the necessary modules through dojo.require () we initiate synchronous HTTP GET requests to get the necessary resources. Since the browser is waiting for the completion of each call, the page load time is greatly increased. So-called “layers” will help us optimize the connection of resources (hereinafter simply - layers).
')
Tasks of using the dojo build system to create your own build:
The layer at the stage of preparation of the assembly is a configuration file that includes the connections we need. For example, let's create a main layer that will be connected on all pages of a web project, let's call it commonlayer.js.
ourcompany.shadow - let's say this is our own module, customizing the dojo.fx.shadow shadow that we want to use.
And for comparison, an additional layer for working with the dijit.Editor editor:
We changed the LinkDialog link insertion plugin for our own needs. We take it out of the standard assembly and call it our own way, as is the case with the shadow. The name change is simple: the original js code of the plugin adds a line with a new ad, for example:
where the name of ourcompany.dijit. ... also speaks of the physical placement of the module in the file system, \ ourcompany \ dijit \ _editor \ plugins \ LinkDialog.js
The layers.profile.js profile describes the necessary layers and naming areas in the dependencies object:
Such a file will create only optimized 2 layers, the rest of the files are simply copied during assembly without changes. But we can take them from the official release. Maybe someone will want to add a profile so that it creates a complete dojo assembly, I did not.
The dojo src version has a special util daddy where you can find build scripts and the shrinksafe utility for obfuscating (optimizing) the code. But make no mistake, "out of the box" it does not work. I had to penetrate and win. Dojo offers two build options, for Windows through build.bat and for linux through build.sh. I spent the assembly on my own computer, in the windows.
The build process itself runs the \ util \ buildscripts \ build.bat file. Edit it by specifying the correct -classpath:
where rhino is the java engine I mentioned above.
It is convenient to start the assembly by specifying the parameters through the makeRelease.bat file. I did it this way, but I am not an expert in writing batch files, I think you will get more elegant:
On the file system, it looks like this:
As you can see, I built the build from source, the “dojo-release-1.6.0-src” directory, into which I put the “ourcompany” folder with the modified modules and resources. To run build.bat, I use the following arguments:
A complete list of arguments is in the documentation .
After completing the build, the directory will look like this:
In the release is almost a New Year's gift - our first custom dojo assembly. In \ release \ ourcompany \ there are two of our layers, each of which is an optimized mighty handful of modules we need to connect.
Connecting layers to the project page:
Working with layers does not exclude standard work with modules via dojo.require (). It should be noted that before connecting dojo.require () checks whether such a module has already been connected, and prevents reconnection.
This article is not only a product of deep reasoning and creative search, but a real experience applied in a real web project. What we got after creating and using our own build:
PS Making changes to dojo modules often brings with it some dependency difficulties. For example, when changing the LinkDialog.js plugin for dijit.Editor, which we included in the build, it was necessary to add the standard files ourcompany \ dijit \ nls \ ru \ common.js (loading.js) to the src version of ourcompany folder. Without this manipulation, the editorlayer.js layer will work with an error.
When studying the mechanism for creating assemblies, I used the documentation on the official dojo toolkit website:
http://dojotoolkit.org/reference-guide/build/
http://dojotoolkit.org/reference-guide/build/simpleExample.html
http://dojotoolkit.org/reference-guide/build/buildScript.html
And we will talk about the assembly system.
What is it and why is it needed
The community offers us a ready-made optimized release, intended for placement on the server and use in web applications. By connecting the necessary modules through dojo.require () we initiate synchronous HTTP GET requests to get the necessary resources. Since the browser is waiting for the completion of each call, the page load time is greatly increased. So-called “layers” will help us optimize the connection of resources (hereinafter simply - layers).
')
Tasks of using the dojo build system to create your own build:
- creating a layer of used modules. All the necessary modules will be collected in 1 file, which will significantly speed up the opening of pages.
- if you need to change the code of dojo modules, we will always work only with source code (src versions of dojo)
- in the presence of such changes, the actions of integrating them into the next updates are minimized
What is needed to create an assembly
- Src version of dojo, which can be found on the download page
- JRE 1.5 and up
- Optionally, our own resources (js, css, etc.) that we want to include in the assembly.
- Profile (profile) - js file that describes the creation of a new assembly.
- Rhino engine from the Mozilla Foundation. Dojo didn’t plan it in his utilities for assembling, although he actively refers to it. You can get it on the Mozilla website.
Creating layers
The layer at the stage of preparation of the assembly is a configuration file that includes the connections we need. For example, let's create a main layer that will be connected on all pages of a web project, let's call it commonlayer.js.
dojo.provide("ourcompany.commonlayer"); // dojo.require("dojo.parser"); dojo.require("dojo.NodeList-fx"); dojo.require("dojo.data.ItemFileReadStore"); dojo.require("dojox.data.AndOrReadStore"); dojo.require("dojo.back"); dojo.require("dojox.fx._base"); dojo.require("dojo.cookie"); // dojo.require("ourcompany.shadow"); ourcompany.shadow - let's say this is our own module, customizing the dojo.fx.shadow shadow that we want to use.
And for comparison, an additional layer for working with the dijit.Editor editor:
dojo.provide("ourcompany.editorlayer"); // dojo.require("dijit.Editor"); dojo.require("dijit._editor.plugins.FontChoice"); dojo.require("dijit._editor.plugins.TextColor"); dojo.require("dijit._editor.plugins.EnterKeyHandling"); // dojo.require("ourcompany.dijit._editor.plugins.LinkDialog"); We changed the LinkDialog link insertion plugin for our own needs. We take it out of the standard assembly and call it our own way, as is the case with the shadow. The name change is simple: the original js code of the plugin adds a line with a new ad, for example:
dojo.provide("ourcompany.dijit._editor.plugins.LinkDialog"); where the name of ourcompany.dijit. ... also speaks of the physical placement of the module in the file system, \ ourcompany \ dijit \ _editor \ plugins \ LinkDialog.js
Creating a profile
The layers.profile.js profile describes the necessary layers and naming areas in the dependencies object:
dependencies = { layers: [ // { name: "../ourcompany/commonlayer.js", resourceName: "ourcompany.commonlayer", dependencies: [ "ourcompany.commonlayer" ] }, { name: "../ourcompany/editorlayer.js", resourceName: "ourcompany.editorlayer", dependencies: [ "ourcompany.editorlayer" ] } ], prefixes: [ // , /dojo, //ourcompany - [ "dijit", "../dijit" ], [ "dojox", "../dojox" ], [ "ourcompany", "../ourcompany" ] ] } Such a file will create only optimized 2 layers, the rest of the files are simply copied during assembly without changes. But we can take them from the official release. Maybe someone will want to add a profile so that it creates a complete dojo assembly, I did not.
We collect
The dojo src version has a special util daddy where you can find build scripts and the shrinksafe utility for obfuscating (optimizing) the code. But make no mistake, "out of the box" it does not work. I had to penetrate and win. Dojo offers two build options, for Windows through build.bat and for linux through build.sh. I spent the assembly on my own computer, in the windows.
The build process itself runs the \ util \ buildscripts \ build.bat file. Edit it by specifying the correct -classpath:
java -classpath "../rhino/js.jar;../shrinksafe/js.jar;../shrinksafe/shrinksafe.jar" org.mozilla.javascript.tools.shell.Main build.js %*
pausewhere rhino is the java engine I mentioned above.
It is convenient to start the assembly by specifying the parameters through the makeRelease.bat file. I did it this way, but I am not an expert in writing batch files, I think you will get more elegant:
@echo off
E:
cd \js\dojoroot
set FLDR=E:\js\dojoroot
echo buid root directory: %FLDR%
cd %FLDR%\dojo-release-1.6.0-src\util\buildscripts
build.bat action=clean,release profileFile=%FLDR%\layers.profile.js version=ourcompany-1.6.0/2 releaseName=On the file system, it looks like this:
As you can see, I built the build from source, the “dojo-release-1.6.0-src” directory, into which I put the “ourcompany” folder with the modified modules and resources. To run build.bat, I use the following arguments:
- action - necessary actions, clean - clear the old build directory, release - create an assembly
- profileFile - profile path
- version - the build version, can be returned via dojo.version
- releaseName - I’m empty; if I set it, a subdirectory with your name will appear in the release folder
A complete list of arguments is in the documentation .
After completing the build, the directory will look like this:
In the release is almost a New Year's gift - our first custom dojo assembly. In \ release \ ourcompany \ there are two of our layers, each of which is an optimized mighty handful of modules we need to connect.
Connecting layers to the project page:
<!-- dojo:--> <script type="text/javascript" src="dojo/dojo.js"></script> <!-- : --> <script type="text/javascript" src="ourcompany/commonlayer.js"></script> <!-- , , : --> <script type="text/javascript" src="ourcompany/editorlayer.js"></script> Working with layers does not exclude standard work with modules via dojo.require (). It should be noted that before connecting dojo.require () checks whether such a module has already been connected, and prevents reconnection.
Result
This article is not only a product of deep reasoning and creative search, but a real experience applied in a real web project. What we got after creating and using our own build:
- significantly increased the download speed of all pages. Download time for personal observations in Firebug and tests webpagetest.org reduced by about a second
- on the main page of the project, where the editor is not used, 129 consecutive HTTP GET requests turned into one (sic!)
- The project survived the upgrade from dojo 1.4 to version 1.6, and now it will be easy to upgrade to each new version
PS Making changes to dojo modules often brings with it some dependency difficulties. For example, when changing the LinkDialog.js plugin for dijit.Editor, which we included in the build, it was necessary to add the standard files ourcompany \ dijit \ nls \ ru \ common.js (loading.js) to the src version of ourcompany folder. Without this manipulation, the editorlayer.js layer will work with an error.
When studying the mechanism for creating assemblies, I used the documentation on the official dojo toolkit website:
http://dojotoolkit.org/reference-guide/build/
http://dojotoolkit.org/reference-guide/build/simpleExample.html
http://dojotoolkit.org/reference-guide/build/buildScript.html
Source: https://habr.com/ru/post/122945/
All Articles