-
Notifications
You must be signed in to change notification settings - Fork 2
Build Process Overview
Table of Contents:
- Goals
- The
web.xmlfile - The
webprojectsfolder - Build-Time Templating
- SASS Compilation
- JS Compression
- Run-Time Template Compilation
- Merging & Pushing
For more exact details of how the builder works, please read the README.md.
The goals of the builder are as follows:
- Build the
web.xmlfile for the server - Run some basic templating over all files in the
webprojectsfolder. - Compile
.scssfiles into.cssfiles - Compress
jsfiles, unless the--debugflag is specified - Compile run-time templates
- Merge
jsandcssfiles to reduce the number of requests to the server - Push files for all websites to the server
- Push files for the webapp to any smartphone apps
Java web applications use a web.xml file to organize things like what URLs correspond to what pages. Google does a thorough job of explaining them here. Our builder generates a web.xml file based off of the patterns described in our servlet-list.csv file.
The webprojects folder contains all the web-related code (e.g. .js and .html files). It is also what undergoes the most work during compilation.
Some subfolders of the webprojects folder have special meanings. Generally, any folder beginning with an _ has some sort of special meaning. These special folders come in two varieties: type folders and platform folders.
Type folders specify what type of content they contain:
-
_imgThese folders contain images -
_jsThese folders contain JavaScript files. Files in this folder which are not.jsfiles will not be pushed to the output code -
_styleThese folders contain.css,.scss, and.sassfiles. Any files with some other extension will not be push to the output code -
_templatesThese folders contain.tmpltandtspecfiles. Any files with some other extension will not be push to the output code -
_rawThese folders contain content which should be pushed to the output code without any sort of modification. -
_ignoreThese folders contain content which should not be pushed to the output code -
_skipThe same as_ignore -
_cssThis is a temporary folder used to hold the contents of the_stylefolder after SASS compilation is complete
Platform folders contain files that should only be pushed to the output code on certain platforms:
-
_debugContents only used if the debug flag is set -
_webContents only used when pushing to server -
_iOSContents only used when pushing to iOS app
Additionally, there is one special file:
-
_orderWhen merging JavaScript or CSS, this file (if present) specifies what order those files should be merged in. If the file does not contain a complete list of all files in the folder, the remaining files will be merged in after the files specified by the file.
All folders which are direct children of the webprojects folder but do not begin with an _ are assumed to represent distinct projects
How our macros actually work is explained elsewhere. Here, we describe where they are defined and which files they are run on.
Currently, macros are defined in the macros file, though they might be allowed to be defined in more places in the future. Those macros are then run in all the files in the webprojects folder, unless those files are inside a _raw or _img folder.
SASS is a tool for simplifying writing CSS. All the .scss or .sass files in a _style folder undergo SASS compilation
SASS library files should be placed in an _ignore folder so that they will not be pushed to production. The main SASS library file is at webprojects/_ignore/main.scss
We use uglifyjs to compress our javascript. However, we only do this compression if we are not in debug mode.
We frequently use lines like:
if({{DEBUG}}) {
...debug code...
}UglifyJS will automatically remove those lines if {{DEBUG}} is false. However, it will spit out a warning message. For this reason, we ignore all warning messages about "side-effect-free statements" or a condition always being true/false.
Incidentally, this method of writing debug-only code is drastically preferred over
IF_DEBUG
...debug code...
END_IFbecause it fits better into the flow of JavaScript
How our run-time templates actually work is explained elsewhere. Here, we describe where they are defined/compiled.
The builder lookes for template files within the server/templates folder and any _templates folder within the webprojects directory. Within such folders, any .tmplt file will be expected to have a corresponding .tspec file, and vise versa. The templates within the server/templates folder are compiled into java and made accessible to the server. The templates in a _templates folder within the webprojects directory are compiled into both java and javascript, and made accessible both to the server and to the javascript files in the same project.
Suppose we have a type folder with the name _type at the path webprojects/f1/f2/.../fn/_type, and the code is currently being outputted to a folder at the path root. Then one of the following happens:
-
Case 1:
typeisjsorcss
The contents ofwebprojects/f1/f2/.../fn/_type(and all subfolders) are merged and placed into the fileroot/f1/f2/.../fn.type -
Case 2:
typeisstyle,skip, orignore
These files are not copied to the output code -
Case 3:
typeisraw
The contents ofwebprojects/f1/f2/.../fn/_typeare copied toroot/f1/f2/.../fn/ -
Case 4: Else
The contents ofwebprojects/f1/f2/.../fn/_typeare copied toroot/f1/f2/.../fn/type/
Projects listed in app-web-projects.csv are pushed to the www folder of all native apps, as well as the war folder of the server. All other projects get pushed to the war folder only.