By default nCoDE discovers available functionality in the scope of the instantiated nCoDE Runtime module. This provides a natural discovery mechanism that is aligned which how requests are resolved within NetKernel. So if you want access to functionality you import its module. That approach works for the most part. Where it doesn't work is when an application relies upon resource in the request scope up and out of the application module. One common use-case for this is when you have a HTTP transport and you want to access information from the HTTP request headers. It is always possible to explicitly reference such resources using identifier literals or using the built-in request builder endpoint but, whilst this is useful, kind of a step backwards from having all our building block endpoints on the palette.
nCoDE supports the ability selected additional palettes from all those discovered in the system. When selected the functionality from those palettes is made available and the spaces which host those palettes are dynamically imported.
When the nCode Runtime is instantiated you must provide it with a dynamicImportConfig parameter to enable this capability. This parameter specifies the identifier of resource which the runtime will expose, it is a dynamic import definition:
Then you should instantiate a dynamic import instance with a config parameter that matches the one specified on the nCoDE runtime:
The settings dialog in the nCoDE Editor has a table of available palettes. Checkboxes show if they are being used or not. In scope palettes are automatically selected and cannot be un-selected. Other palettes can be selected or deselected at will.