@@ -320,6 +320,21 @@ By default, classes are not allowed to access globals and access will result in
320
320
If for your application it makes sense for classes to have access to globals then you can invoke this method
321
321
with ` true ` .
322
322
323
+ ### hasOwnFunctions(boolean value)
324
+
325
+ This controls whether the ` JactlContext ` object will have its own set of functions/methods registered with it.
326
+ By default, all ` JactlContext ` share the same functions/methods registered using ` Jactl.function() ... .register() `
327
+ or ` Jactl.method(type) ... .register() ` (see section below on [ Adding New Functions/Methods] ( #adding-new-functionsmethods ) ).
328
+
329
+ If you would like to have different sets of functions/methods for different sets of scripts you can create different
330
+ ` JactlContext ` objects and register different sets of functions/methods with each object.
331
+
332
+ Note that whatever functions/methods have been registered at the time that the ` JactlContext ` is created will be
333
+ available to scripts compiled with that ` JactlContext ` so it makes sense to register all functions/methods that you
334
+ would like to be available to all scripts before creating any ` JactlContext ` objects.
335
+
336
+ See [ Adding New Functions/Methods] ( #adding-new-functionsmethods ) for more details.
337
+
323
338
### Chaining Method Calls
324
339
325
340
The methods for building a ` JactlContext ` can be chained in any order (apart from ` create() ` which must be first
@@ -331,11 +346,12 @@ JactlContext context = JactlContext.create()
331
346
.environment(new io.jactl. DefaultEnv ())
332
347
.minScale(10 )
333
348
.classAccessToGlobals(false )
349
+ .hasOwnFunctions(false )
334
350
.debug(0 )
335
351
.build();
336
352
337
353
// This is equivalent to:
338
- JactlContext context = JactlContext . create(). build()
354
+ JactlContext context = JactlContext . create(). build();
339
355
```
340
356
341
357
## Compiling Classes
@@ -996,9 +1012,9 @@ This allows you to configure the class name in your `.jactlrc` file and have the
996
1012
in the REPL and in commandline scripts.
997
1013
998
1014
For example:
999
- ``` groovy
1015
+ ``` java
1000
1016
class MyFunctions {
1001
- public static registerFunctions(JactlEnv env) {
1017
+ public static void registerFunctions (JactlEnv env ) {
1002
1018
Jactl . method(JactlType . ANY )
1003
1019
.name(" toJson" )
1004
1020
.impl(JsonFunctions . class, " toJson" )
@@ -1058,7 +1074,7 @@ class MyFunctions {
1058
1074
1059
1075
### Async Instance
1060
1076
1061
- For methods that act on ` JacsalType .ITERATOR` objects, we allow the object to be one of the following types:
1077
+ For methods that act on ` JactlType .ITERATOR` objects, we allow the object to be one of the following types:
1062
1078
* List
1063
1079
* Map
1064
1080
* String &mdash ; iterates of the characters of the string
@@ -1105,7 +1121,7 @@ do more processing when they are resumed.
1105
1121
A naive implementation of ` measure() ` might look like this:
1106
1122
``` groovy
1107
1123
class MyFunctions {
1108
- public static void registerFunctions(JacsalEnv env) {
1124
+ public static void registerFunctions(JactlEnv env) {
1109
1125
Jactl.function()
1110
1126
.name("measure")
1111
1127
.param("closure")
@@ -1239,7 +1255,7 @@ We also need to add a `Continuation` parameter to our function since it is now p
1239
1255
Putting this all together, our class now looks like this:
1240
1256
``` java
1241
1257
class MyFunctions {
1242
- public static void registerFunctions (JacsalEnv env ) {
1258
+ public static void registerFunctions (JactlEnv env ) {
1243
1259
Jactl . function()
1244
1260
.name(" measure" )
1245
1261
.asyncParam(" closure" )
@@ -1291,7 +1307,7 @@ In order for the resume method to invoke the original method, it will need to be
1291
1307
Now our code looks like this:
1292
1308
``` java
1293
1309
class MyFunctions {
1294
- public static void registerFunctions (JacsalEnv env ) {
1310
+ public static void registerFunctions (JactlEnv env ) {
1295
1311
Jactl . function()
1296
1312
.name(" measure" )
1297
1313
.param(" count" , 1 )
@@ -1362,9 +1378,88 @@ Function@727860268
1362
1378
284375954
1363
1379
```
1364
1380
1381
+ ### Registering Functions/Methods for Specific ` JactlContext ` Objects
1382
+
1383
+ In all examples so far, the custom functions/methods that have created have been registered globally using ` Jactl.function() `
1384
+ and ` Jactl.method(type) ` and are therefore available to all scripts within the application.
1385
+
1386
+ If different sets of scripts should have access to different sets of functions/methods, then instead of using ` Jactl.function() `
1387
+ and ` Jactl.method(type) ` to register the function/method, you can create your ` JactlContext ` object and use the ` function() `
1388
+ and ` method(type) ` methods on it to register functions and methods that will only be visible to scripts compiled with
1389
+ that ` JactlContext ` .
1390
+
1391
+ For example:
1392
+ ``` java
1393
+ class MyModule {
1394
+
1395
+ private static JactlContext context;
1396
+
1397
+ public static void registerFunctions (JactlContext context ) {
1398
+ context. method(JactlType . ANY )
1399
+ .name(" toJson" )
1400
+ .impl(JsonFunctions . class, " toJson" )
1401
+ .register();
1402
+
1403
+ context. method(JactlType . STRING )
1404
+ .name(" fromJson" )
1405
+ .impl(JsonFunctions . class, " fromJson" )
1406
+ .register();
1407
+
1408
+ context. function()
1409
+ .name(" getState" )
1410
+ .param(" sessionId" )
1411
+ .impl(MyModule . class, " getState" )
1412
+ .register();
1413
+ }
1414
+
1415
+ public static Object getStateData;
1416
+ public static Map getState (long sessionId ) { ... }
1417
+
1418
+ public void init (JactlEnv env ) {
1419
+ context = JactlContext . create()
1420
+ .environment(env)
1421
+ .hasOwnFunctions(true )
1422
+ .build();
1423
+
1424
+ registerFunctions(context);
1425
+ }
1426
+
1427
+ ...
1428
+ }
1429
+ ```
1430
+
1431
+ The way in which the function/method is registered is identical, except that we use the ` JactlContext ` object rather
1432
+ than the ` Jactl ` class (as shown in the example).
1433
+
1434
+ Note that the ` JactlContext ` will also have access to all functions/methods that have already been registered using
1435
+ ` Jactl.function() ` or ` Jactl.method() ` at the point at which the ` JactlContext ` is created.
1436
+ If other functions/methods are later registered using ` Jactl.function() ` or ` Jactl.method() ` after the ` JactlContext `
1437
+ was created, these additional functions/methods will not be available to scripts compiled with that ` JactlContext ` .
1438
+
1439
+ ### Deregistering Functions
1440
+
1441
+ It is possible to deregister a function/method so that it is no longer available to any new scripts that are compiled.
1442
+ This might be useful in unit tests, for example.
1443
+
1444
+ To deregister a global function just pass the function name to ` Jactl.deregister() ` :
1445
+ ``` java
1446
+ Jactl . deregister(" myFunction" );
1447
+ ```
1448
+
1449
+ To deregister a function from a ` JactlContext ` :
1450
+ ``` java
1451
+ jactlContext. deregister(" myFunction" );
1452
+ ```
1453
+
1454
+ To deregister a method:
1455
+ ``` java
1456
+ Jactl . deregister(JactlType . STRING , " lines" );
1457
+ jactlContext. deregister(JactlType . LIST , " myListMethod" );
1458
+ ```
1459
+
1365
1460
## Example Application
1366
1461
1367
- In the ` jacsal -vertx` project, an example application is provided that listens for JSON based web requests and
1462
+ In the ` Jactl -vertx` project, an example application is provided that listens for JSON based web requests and
1368
1463
runs a Jactl script based on the URI present in the request.
1369
1464
1370
1465
See [ Example Application] ( https://github.com/jaccomoc/jactl-vertx#example-application ) for more details.
0 commit comments