ZeroTouch Methods Best Practice for List Lacing?

I’m making my on ZeroTouch dll. But I’m unsure on what the best practices are.

Firstly, General Question: do you know of documentation that gets into the ZeroTouch weeds? What reference do you like to use when developing zero touch nodes?

Secondly, Specific Question: My node will have a list of strings passed into it. Is better practice to have a method that takes a string as the parameter? Or should my method take a list and return a list?

Where would I find documentation explaining how zero touch nodes handle lacing and parameter input?

Generally for custom nodes of any sort I believe most programmers will check if an input isn’t a list object, and if it isn’t will turn that into a list with it instead so it is iterable. On the way out, you can check if the list only has one object and if so return the one item in the list. Not 100% sure if that applies to zero touch nodes but for Python i generally use those techniques to handle list/item possibilities.

1 Like

This resource is great for getting started:

Generally speaking, zerotouch nodes behave like ootb nodes by handling lists for you.

In python, you have to loop and iterate through lists and zero-touch mostly does this on its own. I say mostly because if you need to maintain specific list orders (for multiple inputs), you should build your node to take lists and work it out.

For resources related to zerotouch, archilab is a good reference and I have rhythm open source as well

4 Likes

C# nodes implicitly cast single inputs to lists if your input type is a list so there’s no need to check if the input is a list, plus you can’t check it anyway due to the way Dynamo handles the input.

Also, avoid list inputs unless you absolutely need it. If you stick with single inputs, you can leverage Dynamo’s built-in lacing mechanism - which iterates over collections (if input) without you needing to do anything - without resulting in unexpected outputs. That’s also why there’s no documentation on it since ZT nodes provide no access to inputs prior to execution nor lacing, other than the attribute which enables you to disable lacing if you don’t want it. Single inputs will make your node easier for the end user as it will behave as expected with the various lacing options, and easier for you as a developer too.

5 Likes

Thanks for the fantastic answers. They have been huge help solving.

To clarify my issue a little more, I’m passing data by marshalling a structural analysis program (ETABS). But the api relies on passing arrays by reference (so C# is the better option than Python). I was trying to decide if it made sense to create a new marshal per list item, or a single marshal for one list.

Not my wheelhouse, but I’m assuming the marshal objects are essentially just pointers. So it won’t effect the performance creating thousands of individual pointers to same running process. Correct me if I’m wrong in this assumption, but that’s the hypothesis I’m working with.

Thanks so much for taking time to explain the processes!