Extending : Common Condition Extension : Sample implementation of version control : Implementing the sample
  
Implementing the sample
Tooling part
In this sample, we will generate all the condition JS file to global static web project - 40_GlbStaticWeb.
To achieve this, we use a property file named condition.conf, for every project and in the same location as condition.transaction, to store the location of the JS:
This graphic is described in the surrounding text.
In this file, the content is:
project=40_GlbStaticWeb
path=/WebContent/js/condition/
This means the JS location is:project\path. So all the condition files are in the folder: 40_GlbStaticWeb\WebContent\js\condition.
This folder is like:
This graphic is described in the surrounding text.
It includes five files. Among them, the pattern of condition JS files is: <projectName>_cond_timeStamp.js.
10_GlbDefs_cond_20120927110232.js is the JS of project 10_GlbDefs
30_LocalWeb_cond_20120927111018.js is the JS of project 30_LocalWeb
conditions_version.confcantains the last version of above JS file.
Note This file is just used by tooling. The version manager will write the last version to this file.
conditions_version.js contains the last version of above JS file.
Note Note that this file is a mirror of conditions_version.conf and it is designed for runtime use.
conloader.js
This is the condition loader used in client side, and it is designed to load the last version of JS file.
Runtime part
conditions_version.js and conloader.js mentioned above are part of runtime.
The template (30_LocalWeb\WebContent\templates\template_debug.ftl) is changed a little to load the last version of JS file:
This graphic is described in the surrounding text.
In conloader.js, loadConditions method will load conditions_verison.js first and then load the conditions according to the order of con_queue_order
See also
Sample implementation of version control