ZT Library Organization

Developers
1

There are a few other posts related to this topic, but I wasn’t able to find what I needed and am opening a new one. Let’ say we have a zero touch library like this:

Assembly = Food
Namespace = Fruit
Class = Apple
Class = Strawberry
Class = Blueberry

When importing to Dynamo, the library would look like this by default (drill down to see more):

Food
Fruit
Apple
Strawberry
Blueberry

But what if I want to put Strawberry and Blueberry together into a group called “Berries” without adding a new namespace for Food.Fruit.Berries? You can accomplish that with explicit nodes with the [(NodeCategory)] attribute, but in my testing that attribute doesn’t work for ZT nodes aside from specifying Create, Action, and Query. I’ve also had some success using a customization XML file per this guide, but only to the point where I can remap an entire namespace but not individual classes within that namespace. It seems like this is what the <classes> tag should do, but I’m lost on what that actually does and haven’t seen any examples to explain further.

<classes>
    <!--Remap Class Names-->
    <class name="Autodesk.Dynamo.MeshToolkit.Display.MeshDisplay" shortname="MeshDisplay"/>
    <class name="Autodesk.Dynamo.MeshToolkit.Mesh" shortname="Mesh"/>
</classes>

So in a nutshell, I’m trying to organize my package library into different levels without adding a ton of namespaces.

2

You cant…not with ZT nodes as the customisation XML doesn’t work. The NodeCategory attribute only works with Node Model nodes. Your only option is to add a new workspace.

3

Thanks Thomas. That’s too bad…I guess I’ll just be stuck with This.Is.The.Longest.Fully.Qualified.Class.Name.Ever.Too.Bad.It.Cant.Be.Shortened

4

:rofl:
Just pray no one ever see’s it. But yeah, ZT forces you down some pretty ugly paths unfortunately :man_facepalming:

1 Like
5

The reason I’m trying to get away from such long names is that it makes for some pretty cryptic warning messages. You end up with:

Class.NodeName expects argument types (This.Is.The.Longest.Fully.Qualified.Class.Name.Ever.Too.Bad.It.Cant.Be.Shortened, string, double)

…so on and so forth. Not very easy for the end user to wade through.

6

Its a big problem I agree - you might just have to compromise then; as a general good programming principle you want to keep your namespaces as flat as possible, which in turn will lead to a less structured node library organisation, but if you have well named classes then it should make up for it from the users standpoint.

4 Likes