UDT parameter vs Indirect Binding in Template development

In development of template for udt, it’s possible to use two different way to pass value from a instance of udt to template. You can add a parameter and select udt as type, or you can add string parameter to use to pass tag path.
I would yours opinion on what is better to use in development of template UDT parameters or indirect tag.
I drawn up a list with pro e cons of both

UDT Parameter:
Pro:

  • one whole object with all subtags;
  • Drag&Drop
  • Subtags accessible as property
  • simplicity to combine different subtag in expression binding

Cons:

  • It depends of a specific tag provider, there isn’t “shared” tag provider;
  • Slower then indirect binding;
  • Not general and it’s necessary to duplicate whene two udt definition have same subtags but different driver protocol;

Indirect binding
Pro:

  • Faster than udt parameter
  • Better flexibility on udt with same subtag but udt different
  • Better in shared, indipendent of tag provider

Cons:

  • No one object, link any subtag
  • Two step to combine different subtag in expession binding
  • No drag&drop
1 Like

Good summary. FWIW, I always use indirect binding. Execution speed is a prime concern for me – one of the points of having templates is to be able to make many instances efficiently. UDT bindings erase that value. IMNSHO, templates based on UDT bindings are effectively non-portable.

I feel like UDT parameters could really be great. But right now… nope. I think if they could only load whats necessary (as opposed to loading the wholeUDT) and if they could handle slight variances better, that’d be so much better. But for now yeah - if you have multiple slightly different UDTs that use the template and/or many instances of a template w/ a UDT parameter, deeeeefinitely gotta go with indirect.

We follow the same approach. We tried to use UDT bindings on one project, noticed the performance hit, and have not used them since.

1 Like