When writing C# code for Divooka plugins, a few idiomatic patterns and XML annotations ensure that your methods and types appear cleanly in the graph editor. In Divooka, any method you intend to expose as a standalone node should be declared as a public static function. Because static methods hold no instance state, Divooka automatically generates a node whose input pins correspond to the method’s parameters and whose primary output pin reflects the method’s return type. For example, consider a simple static method that computes a square:
/// <summary>
/// Returns the square of an integer.
/// </summary>
public static int Square(int x) => x * x;
When this code is loaded, Divooka presents a node named “Square” with one input (x of type int) and one output (an automatically named Result of type int), without requiring any extra wiring or boilerplate.
In addition to return values, C#’s out parameters are supported as additional output pins. If you declare a method like this:
/// <summary>
/// Divides an integer and returns quotient and remainder.
/// </summary>
public static int Divide(int dividend, int divisor, out int remainder)
{
remainder = dividend % divisor;
return dividend / divisor;
}
Divooka will create two outputs—one for the return value (quotient) and one for the out parameter (remainder). Crucially, out parameters do not appear as inputs on the node; instead, they automatically become extra output pins. This makes it straightforward to expose multi-value methods without cluttering the node’s input side.
By contrast, instance methods are hidden by default unless you explicitly opt in. To expose an instance method in a pure-dataflow graph (so it behaves like a static function), add <const>true</const> in its XML documentation. For example:
public class MathHelpers
{
/// <summary>
/// Adds two numbers together.
/// </summary>
/// <const>true</const>
public int Add(int a, int b) => a + b;
}
With <const>true</const>, Divooka treats Add as though it were static—displaying a node that takes two integers and returns their sum. Omitting <const> tells Divooka that the method likely depends on internal state or side effects, so it remains available only within procedural contexts, where an explicit object instance is maintained.
XML documentation is the source of truth for node metadata (tooltips, display names, input formats, and more). Divooka recognizes several tags and attributes:
<summary> and <remarks> populate the node’s tooltip or help panel, providing users with contextual guidance.<param name="…" textFormat="…"> controls how Divooka renders or constrains that parameter—examples include textFormat="text" for plain text or textFormat="Password" to mask sensitive inputs.<snap>URL</snap> links to a screenshot that appears in the node’s documentation pane, helping end-users understand usage at a glance.<hidden>true</hidden> prevents the method or type from appearing in the toolbox, even if it would otherwise be discoverable.<const>true</const> (on instance methods) forces Divooka to treat that method like a pure function in dataflow graphs.For instance, if you write:
/// <summary>
/// Executes a query and returns a DataGrid.
/// </summary>
/// <snap>https://cdn.example.com/snaps/QueryNode.png</snap>
public static DivookaDataGrid Query(string sql, ODBCConfiguration? config = null)
{
// Implementation omitted…
}
Divooka will display “Executes a query and returns a DataGrid” as the tooltip, and it will show the referenced image when users inspect the node’s documentation. If you add <hidden>true</hidden>, Divooka will hide that method from the user-facing toolbox entirely, even if other exposure conditions are met.
Divooka also supports delegate-based nodes: if a static or instance method includes a Func<…> or Action<…> parameter, that parameter becomes a lambda placeholder in the graph. For example:
/// <summary>
/// Applies a lambda to each element in an integer array.
/// </summary>
public static int[] Map(int[] items, Func<int, int> transformer)
{
return items.Select(transformer).ToArray();
}
When dragged into a graph, “Map” shows an items input, a transformer subgraph placeholder, and an int[] output. Under the hood, Divooka compiles the user’s subgraph into a delegate, applying it to every element at runtime.
Note that, as of Divooka 0.8.5, generic methods and classes are not supported. Even if you declare:
public static T Identity<T>(T value) => value;
Divooka ignores it. To expose functionality, you must use concrete types (for example, int Identity(int) or string Identity(string)). Future releases may add generic support, but for now, design your plugin API without type parameters.
Finally, Divooka does not recognize inheritance hierarchies or polymorphic dispatch when populating the toolbox. If you define a base class and a derived class that both implement Compute(double), Divooka lists both separately; it will not combine them under a shared “Compute” node or perform runtime type-based dispatch. If you require polymorphic behavior, implement explicit wrapper methods or leverage procedural contexts to inspect types at runtime.
Below is a summary of the XML tags and attributes most useful when annotating your C# code for Divooka. Use this as a quick reference when writing documentation comments:
| Tag / Attribute | Purpose | Notes |
|---|---|---|
<summary>…</summary> |
Provides the node’s main description. | Appears as tooltip text in the graph editor. |
<remarks>…</remarks> |
Offers additional explanatory text. | Shown in the detailed documentation pane, below the summary. |
<param name="…" …>…</param> |
Describes a parameter and (optionally) its input format. | Attributes: textFormat="text" (plain text), textFormat="Password" (masked input), etc. |
<snap>URL</snap> |
Embeds a screenshot or illustration URL. | Divooka displays this image in the node’s documentation pane for visual guidance. |
<hidden>true</hidden> |
Hides the method or type from the toolbox. | Even if other criteria expose it, this tag forces Divooka to omit it from the UI. |
<const>true</const> |
Marks an instance method as a pure function in dataflow contexts. | Without this, instance methods are available only inside procedural contexts. |
<displayName>…</displayName> |
Overrides the automatically inferred display name for a node. | If omitted, Divooka uses the CLR‐name; providing this tag lets you specify a user-friendly label. |
<returns name="…">…</returns> |
Names or describes the return type. | Rarely needed—Divooka infers return types automatically; use this only to declare custom return pin names. |
Use these tags consistently to give users a polished, self-documenting experience when they drag your custom nodes into a graph.
TODO:
Also See: