Creating dynamic slots from Hyperlambda
This project provides the ability to create, invoke (signal), modify, inspect, and delete dynamic slots for Magic. More specifically, this project provides the following slots.
- [signal] - Invokes a dynamically create slot that has been created with the [slots.create] slot
- [try-signal] - Invokes a dynamically create slot that has been created with the [slots.create] slot, but will not throw exceptions if the slot doesn’t exist
- [slots.create] - Creates a dynamic slot, that can be invoked with the [signal] slot
- [slots.get] - Returns the entire lambda object for a slot that has been previously created with the [slots.create] slot
- [slots.delete] - Deletes a slot that has been previously created with the [slots.create] slot
- [slots.exists] - Returns true of the given slot exists
- [return-nodes] - Returns a bunch of nodes to caller from inside of your slot
- [return-value] - Returns a single value to caller from inside of your slot
- [return] - Returns either a list of nodes, or a single value, or both, depending upon the results of its expression, or whether or not it has a static value, or a list of nodes
- [slots.vocabulary] - Returns the names of all dynamically created slots
/* * First we create a dynamic slot. */ slots.create:foo return-value:int:57 /* * Then we invoke it. */ signal:foo
After evaluation of the above Hyperlambda, the value of the [signal] node will be 57. Notice, if you invoke [slots.create] for a slot that has already been created, the old slot will be overwritten with the new lambda object you pass into it. Also notice that if you try to invoke a slot that doesn’t exist, or you try to get its content, an exception will be thrown.
Also realize that when you create a slot, it is not persisted in any ways - Implying if the web server process is restarted, your slot will disappear. To avoid this, put the creation of your slot inside a file in a folder called “magic.startup” in your module’s folder, e.g. “/files/modules/foo-module/magic.startup/create-slot.hl”. All files inside of modules that exists within a “magic.startup” folder will be executed every time your web server restarts for some reasons.
Creates a dynamic slot that can be invoked using [signal]. Below is an example.
Notice, the above slot aren’t persisted in any ways, implying if your web server restarts its process, your slot is removed. If you want to make sure your slots becomes a permanent part of your application, you need to make sure you are somehow creating it during server startup, which can normally be done on a per module basis, by putting a Hyperlambda file into your module’s “magic.startup” folder, which makes sure the code is executed during startup of your web app.
Invokes a previously created dynamic slot. Assuming you have executed the above code snippet, you can invoke the slot using the following Hyperlambda.
After evaluating the above Hyperlambda, the [signal] node will end up having a value of “57”.
Notice - This slot obeys by the rules of [whitelist] invocations from magic.lambda, allowing you to declare a list of dynamic slots, which are exclusively allowed to be invoked temporarily inside of an invocation to whitelist, allowing you to restrict some piece of potentially unsafe code to only signal a pre-defined list of dynamically created slots. Below is an example.
slots.create:foo1 return-value:Safe slots.create:foo2 return-value:Unsafe whitelist vocabulary signal signal:foo1 .lambda // Assuming you have a [foo1] slot created, this will work signal:foo1 // This will throw, since [foo2] is not whitelisted signal:foo2
Basically, only the slots declared in the above [vocabulary] will be allowed to be invoked inside of the above [.lambda] object. You must have your dynamic slots declared as signal:slot-name, such as the above illustrates. And in order to signal dynamic slots at all, you’ll need to (obviously) whitelist [signal] itself, as illustrated in the above code. Read more about [whitelist] in the magic.lambda project. Inside your slots though any [whitelist] invocations will simply be ignored, allowing you to whitelist a single dynamic slot, for then to ignore what the slot itself is doing internally. This might create security issues for you if you have dynamically created slots that for some reasons execute lambda object supplied to them. Hence as a general rule of thumb, you should avoid whitelisting slots that executes lambda objects supplied to them.
Returns the entire lambda code for a previously created dynamic slot. Example can be found below.
slots.create:foo return-value:int:57 slots.get:foo
Deletes a previously created dynamic slot. The following example will throw an exception.
slots.create:foo return-value:int:57 slots.delete:foo // Throws exception, since [foo] no longer exists. slots.get:foo
Returns a bunch of nodes (lambda) from your slot. Can only be invoked from the inside of a dynamically created slot, and other slots explicitly creating a return context. An example can be found below.
slots.create:foo return-nodes integer-value:int:57 string-value:Foo bar signal:foo
Returns a single value from your slot. Can only be invoked from the inside of a dynamically created slot, and other slots explicitly creating a return context. An example can be found below.
slots.create:foo return-value:This becomes the returned value from your slot signal:foo
Returns true if the specified slot exists. Example can be found below.
slots.create:foo return-value:Blah, blah, blah ... slots.exists:foo slots.exists:DOES-NOT-EXISTS
Returns the names of all dynamically created slots to caller. Example can be found below.
The source code for this repository can be found at github.com/polterguy/magic.lambda.slots, and you can provide feedback, provide bug reports, etc at the same place.