Skip to content

Update Packages from 1.3 to 2.0

Craig Long edited this page Apr 11, 2018 · 19 revisions

Custom Nodes

Organizing Custom Nodes in librarie.js

Known Issues: A coinciding custom node name and category name at the same level in librarie.js causes unexpected behavior. QNTM-3653

Zero Touch Nodes

Node Model Nodes

Json Constructor

The most common change required for updating nodes derived from the NodeModel base class (or related, ie DSDropDownBase) is the need to add a Json constructor to your class. Your original constructor will still handle initializing a new node that is created within dynamo (via the library for example). The Json constructor is required to initialize a node that is deserialized form a saved .dyn file. The Json constructor differs from the base constructor in that it has PortModel parameters for the inPorts and outPorts which are provided by the Json deserialization logic. The user logic to register the Ports for the node is not required as the data exists in the .dyn file. An example of the Json constructor looks like this:

using Newtonsoft.Json; //New dependency for Json

………

[JsonConstructor] //Attribute required to identity the Json constructor

//Minimum constructor implementation. Note that the base method invocation must also be present.

FooNode(IEnumerable<PortModel> inPorts, IEnumerable<PortModel> outPorts) : base(inPorts, outPorts) { }

Any user logic which existed in the class constructor that involve initialization of specific data that is serialized into the .dyn file (for example setting Port registration, lacing strategy, etc) are not required to be repeated in this constructor. Other user logic however must be duplicated in the Json constructor (for example, initializing event handlers for the node).

Examples can be found here in the DynamoSamples repo -> ButtonCustomNodeModel, DropDown, or SliderCustomNodeModel

Public Properties and Serialization

Previously a developer could serialize and deserialize specific model data to the xml document via the SerializeCore and DeserializeCore methods. These methods still exist in the API but will be deprecated in a future release of Dynamo (an example can be found here). With the Json.NET implementation now public properties on the NodeModel derived class can be serialized to the .Dyn file directly. Json.Net provide multiple attributes to control how the property is serialized.

This example which specifies a PropertyName is found here in the Dynamo repo.

[JsonProperty(PropertyName = "InputValue")]

public DSColor DsColor {...

This example also specifies a serialization method to convert the property to a string is found here in the Dynamo repo.

[JsonProperty("MeasurementType"), JsonConverter(typeof(StringEnumConverter))]

public ConversionMetricUnit SelectedMetricConversion{...

Finally public properties that are not meant for serialization need to have the [JsonIgnore] attribute added. When the nodes is saved to the Dyn file this insures this data is ignored by the serialization mechanism and will not cause unexpected consequences when the graph is opened again. An example of this can be here in the Dynamo repo.

Input and Output Port APIs

One common occurrence in NodeModel nodes affected by 2.0 API changes is port registration in the node constructor. Looking at examples in the Dynamo or DynamoSamples repo you previously will have found use of the InPortData.Add() or OutPortData.Add() methods. Previously in the Dynamo API the InPortData and OutPortData public properties were marked as deprecated. In 2.0 these properties have been removed. Developers should now use InPorts.Add() and OutPorts.Add() methods. Additionally these two Add() methods have slightly different signatures:

InPortData.Add(new PortData("Port Name", "Port Description")); //Old version valid in 1.3 but now deprecated

vs

InPorts.Add(new PortModel(PortType.Input, this, new PortData("Port Name", "Port Description"))); //Recommended 2.0

Examples of converted code can be found here in the Dynamo Repo -> DynamoConvert.cs, or FileSystem.cs

The other common use case that is affected by the 2.0 API changes relates to the methods commonly used in the BuildAst() method to determine node behavior based on the presence or absence of port connectors. Previously HasConnectedInput(index) was used to validate a connected port state. Developers should now use the InPorts[0].IsConnected property to check the port connection state. An example of the this con be found in ColorRange.cs in the Dynamo Repo.

Package Organization

Releases

Roadmap

How To

Dynamo Internals

Contributing

Python3 Upgrade Work

Libraries

FAQs

API and Dynamo Nodes

Clone this wiki locally