Adding custom palettes to nCoDE is easy. Palettes will automatically be discovered by the runtime and will be automatically used if you import a space containing a palette.
The structure of CDEPalette.xml is as follows (here is an example from the HTTP Server module):
Endpoints do not need to be in groups specified in the same definition. This allows for some groups to contain collections of endpoints from many spaces. However it is important that the palette entry for an endpoint is in the same space as the definition of that endpoint.
Sometimes it is useful to pre-constrain an endpoint by providing it with one or more preset arguments. One example is the http:request endpoint from above. The definition above allows use of the endpoint but it requires a path argument as defined in it's documentation. In this case the path may be one a set of predefined values so we can specify each one and create a set of palette items don't require input arguments:
This section covers an advanced topic which will rarely be needed. Some endpoints inject resources into scope when they request their arguments. In order for these injected resources to be available the endpoint definition can specify them. Here is an example from the catch exception accessor in DPML:
By default when you construct an endpoint the standard module base classes create basic meta data to
describe the endpoints interface this is driven by the grammar that you provide for your endpoint.
This is enhanced when you provide tags like
This interface metadata is used by the documentation system to provide a datasheet style documentation boilerplate and also by ncode to make smart decisions about how to connect together endpoints.
Further refinement of the metadata to determine argument and response typing can be done inside the constructor for the endpoint using these standard declarations.