WARNING: This server provides a static reference view of the NetKernel documentation. Links to dynamic content do not work. For the best experience we recommend you install NetKernel and view the documentation in the live system .

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.

Creating new palette entries

Each public space may expose a palette definition. Palette definitions are discovered using spaceAggregateHDS looking for the resource addressed as res:/etc/system/CDEPalette.xml.

The structure of CDEPalette.xml is as follows (here is an example from the HTTP Server module):

<palette>
  < !-- define a new palette group. id attribute must be globally unique name attribute is the displayed name of the group order attribute allows optional relative positioning of palette groups in the UI -->
  <group id="http" name="HTTP" order="10" />
  < !-- define a new endpoint id attribute specifies the endpoint identifier as defined in the space definition - it is important to specify an endpoint id rather than let if default to an autogenerated one name attribute optionally overrides the endpoints name obtained from it's metadata. group attribute specifies which group the endpoint will appear in order attribute allows optional relative positioning of endpoints within a group in the UI class attribute allows optional specification of endpoint type (currently only data-source supported) -->
  <endpoint id="http:request" name="HTTP Request Header" group="http" order="1" class="data-source" />
</palette>

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.

Pre-constrained Endpoints

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:

<palette>
  < !-- define a new endpoint with a pre-constrained argument idp attribute specifies the unique id for the palette item argument element specifies a value for the named argument -->
  <endpoint id="http:request" idp="http:request:params" name="HTTP Request Params" group="http">
    <argument name="path">params</argument>
  </endpoint>
  <endpoint id="http:request" idp="http:request:header:useragent" name="HTTP Request User-Agent" group="http">
    <argument name="path">header/User-Agent</argument>
  </endpoint>
  < !-- etc... -->
</palette>

Dealing with injected resources

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:

<endpoint id="dpml:exception" group="core">
  <injected>
    <to>catch</to>
    <n>caught</n>
    <t>REPRESENTATION</t>
    <s>org.netkernel.layer0.representation.WrappedThrowable</s>
    <uri>dpml-arg:exception</uri>
  </injected>
  <injected>
    <to>catch</to>
    <n>caught-id</n>
    <t>REPRESENTATION</t>
    <s>java.lang.String</s>
    <uri>dpml-arg:exception-id</uri>
  </injected>
</endpoint>
In this release this topic will not be discussed further.

Extending endpoint metadata

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 and on the endpoint declaration your module.xml.

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.