@@ -116,7 +116,9 @@ For the module path, you can specify it either relative to the runtime working d
116
116
e.g., `module : ./path-from-root/validations.js`, or you can use the location of the configuration file as a relative
117
117
anchor, e.g., `module : $CONFIG_DIR/validation.js`.
118
118
119
- # # Initialization for CAP Projects
119
+ # # Initialization
120
+
121
+ # ## For CAP Projects
120
122
121
123
CAP projects, will use the library as a [cds-plugin](https://cap.cloud.sap/docs/node.js/cds-plugins). Their
122
124
initialization settings are in `package.json`. For example :
@@ -139,7 +141,7 @@ after the [bootstrap](https://cap.cloud.sap/cap/docs/node.js/cds-server#bootstra
139
141
Using the feature toggles in CAP projects also enables a [REST service]({{ site.baseurl }}/service/), where toggles can
140
142
be read and manipulated.
141
143
142
- # # Initialization for Non-CAP Projects
144
+ # ## For Non-CAP Projects
143
145
144
146
Other projects will need to use the corresponding filepath, in order to initialize the feature toggles instance in code.
145
147
@@ -223,7 +225,7 @@ The following environment variables can be used to fine-tune the library's behav
223
225
# # User Code
224
226
225
227
In this section, we will assume that the [initialization](#initialization) has happened and the configuration contained
226
- a feature toggle with the key `/srv/util/logger/logLevel`, similar to the one described [here](#format ).
228
+ a feature toggle with the key `/srv/util/logger/logLevel`, similar to the one described [here](#configuration ).
227
229
228
230
# ## Reading Feature Value
229
231
@@ -349,4 +351,4 @@ registerFeatureValueValidation("/srv/util/logger/logLevel", (newValue) => {
349
351
350
352
{: .info }
351
353
Simple validation rules that can be expressed as a regular expression should use the associated
352
- validation [configuration](#format ) instead.
354
+ validation [configuration](#configuration ) instead.
0 commit comments