# Best practices and opinions about templtaes? **URL:** \ **Category:** Ignition\ **Tags:** ignition80\ **Created:** [May 8, 2020, 12:35pm UTC](https://forum.inductiveautomation.com/t/best-practices-and-opinions-about-templtaes/34569 "2020-05-08T12:35:34Z")\ **Posts on this page:** 1\ **Showing post:** 2
**Author:** ![brandon1](https://avatars.discourse-cdn.com/v4/letter/b/ea666f/32.png) [@brandon1](https://forum.inductiveautomation.com/u/brandon1)\ **Post date:** [May 8, 2020, 7:23pm UTC](https://forum.inductiveautomation.com/t/best-practices-and-opinions-about-templtaes/34569/2 "2020-05-08T19:23:38Z")
Let me say first off that as I have been using the software, I see more and more usefulness out of using templates. I used to think that I should only use templates when it is something that is used everywhere, but I have started to shift to using templates for more and more objects because of one important reason. Reusability. I can take a simple numeric display for example and replicate it across and entire system. And when the owner wants to add some special function to this object. No problem! Let me just pull up the template definition and I'm done within seconds. Anyways here is my feedback: > [@bkarabinchak.psi](#): > > Template parameters must have some naming convention, given that they are the only way to both input data to the template and get data out of the template. I’m of the opinion that template parameters should be named things like “in\_somePropery” “out\_someProperty” so people know what they have to provide and what they are getting without any additional reading of the code required. I must admit, it is very rare that I use template parameters as outputs. That would involve doing some scripting inside of your template to pass values which I have always been wary off. Maybe ask the designer of the template why they need this output parameter in the first place since it's not really directly supported by templates in Vision. > [@bkarabinchak.psi](#): > > All non-inputs/outputs should be hidden inside the template. Not sure what you mean by this? They are hidden unless you go digging into the template instance with scripting... > [@bkarabinchak.psi](#): > > To UDT or not to UDT as a paramter? We have a bunch of templates that work with a specific UDT structure, and that seems ok until you take it to another project that does not have the same UDT strucuture. I think perhaps the “in\_” parameters should be bound directly to the property of the UDT and then you can always template repeat anyways, this way even if you have two differently shaped UDT’s with different property names, you can still utilize the same template You may find this post helpful to answer your question. [To UDT or not to UDT. That is the question](http://forum.inductiveautomation.com/t/to-udt-or-not-to-udt-that-is-the-question/32703) > [@bkarabinchak.psi](#): > > Templates should be as encapsulated as possible, templates should not rely on windows or other components to do calculations for it (something I’ve seen that made my pull my hair out), if you need something done within the template there should be a parameter that’s changed to do it and that’s it, no outside work necessary. 100% agree! My philosophy with templates is to make them as simple as possible so they have the most use cases. I would rather group four templates together to form a 'unit' than to have all four templates crammed into one for simplicity and reuse potential. > [@bkarabinchak.psi](#): > > The proper level of abstraction - this is a tough one. I’ve seen many templates that accept database table names/columns for read/write capabilities, and I see the use in it. Is there an argument against this? I even saw a template that passed on full on queries and dataset to pass onto a popup window that would be run with the submit button on the popup was pushed. While I can see the convenience if you can get it working right and know how it works, it did take me a while to understand and would take a while for another developer to understand before using. To me, a well designed template will use either a bound property, like an open status for a valve, or a tag path, like a command boolean to accomplish its task. It sounds like you are using templates to do something that would be better suited for a customized popup window. > [@bkarabinchak.psi](#): > > Do you put all your properties on the root container? One coworker brought this up so that way everything is there for looking at, and you don’t have to parse the components to see where things are coming from. I’m used to doing things like putting a “whereClause” property on every component that contributed to a where clause in a query, but I can see how it might be confusing, but at the same time I hate when root containers are over populated. Generally yes. Most of the time objects within the template will be bound either to custom properties on the root container or the template parameters themselves. I hope this is helpful. As with anything, good template design is an acquired skill. For me personally, I try to make mine as simple as possible. The less amount of scripting the better. 👍 --- _[View the full topic](https://forum.inductiveautomation.com/t/best-practices-and-opinions-about-templtaes/34569)._