osg-rules-updater v0.2.22
Synopsis
prules -s -t -w --cheats
source - path to source in a local folder target - URL to target database (includes target env) world-type - name of rules-type document --cheats - allow cheats
Techincal Info
Project structure
CLI context is ./bin/prules
Logic of all context switches and their defaults is implemented at ./lib/params.js
The module logic is ./lib/rules-updater.js
There is a test fixture on ./test/rules_0/
Parameters and Context switches
implemented at ./lib/params.js
3 levels of cascading defaults:
1 - CLI parameter - switches are described with 'optimist'. 2 - prules.config.js - options that are commonly used - save time in providing them every time 3 - defaults - some of the switches have hardcoded defaults
(*) names are not the same. CLI Switches have short names, but they support full names too. prules.config uses shorter names of it's own
The module logic
implemented at ./lib/rules-updater.js
Waterfall with these stages: 1 - getWorldType - gets World Type document from target DB 2 - setVersion - checks version 3 - setParts - update parts on the document 4 - updateWorldType - puts the updated document back to the target DB
important section is the strategy pattern of setPart.
Since in JS functions are first-class objects - the function itself is the dictionary of strategies.
setParts uses a forEachLimit( .., 1 , ...) - for two reasons:
1 - resolving dependency in chdir in async way will make things a little complicated 2 - the output is clearer this way
it is OK to slow down this simple CLI tool...
10 years ago
11 years ago
11 years ago
11 years ago
11 years ago
11 years ago
11 years ago
11 years ago
11 years ago
11 years ago
11 years ago
11 years ago
11 years ago
11 years ago
11 years ago
11 years ago
11 years ago
11 years ago
11 years ago
11 years ago
11 years ago
11 years ago
11 years ago