Best practices and opinions about templtaes?

[bkarabinchak.psi]

My company has decided to try to start curating our “best” templates from all our projects and decding on how in the general we want to design our templates across our projects, so that one developer can pick up where another left off with minimal re-reading of the code required.

To start this off we are going to have everyone pick their favorite “valve” template next week and we’re going to discuss what we like and don’t like about each one and based on that try to make some design decision that we will try to use across all our templates.

Personally I think us coming up with guidelines and conventions will be way more helpful than a template library as we have projects with different versions all over the place and no project requirement is exactly the same.

What’s your opinion about templates/best practice methodology?

I have a few points I want to made -

1. 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.

2. All non-inputs/outputs should be hidden inside the template.

3. 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

4. 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.

5. 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.

6. 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.

Thoughts? I know this isn’t the the typical question for this forum but as developers I’m sure many of you have lots of opinions about this and I want to hear them.

[brandon1]

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

@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.

[bkarabinchak.psi]

For outputs in the parameters, one common example I have in my application is a Tree component that we have as a template Selecting items on it provides id’s for filtering in tables, and afaik, the only way to expose these for table where clauses to use is to put them in template parameters as well, though I guess client tags might work but that seems like a misuse of tags and seems to not be encapsulated.

[brandon1]

Wait. Are you just encapsulating a tree component in a template?

[bkarabinchak.psi]

Not just a tree, techincally we have a hidden table on the tree that actually loads the data, so that we can take advantage of the “propertiesLoading” property so we can indicate when the tree is loading, as well as a text input box to search the tree. Also, the template was made in Ignition prior to the Named Queries functionality but that would probably take over some of the reason of the template now.

[Sanderd17]

@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.
• All non-inputs/outputs should be hidden inside the template.

For me, templates should ideally have very little parameters. Just one tagpath to display, and perhaps one output for the return value you mention. Usually if you have minimal parameters, figuring out their purpose is simple.

I like templates to be very simple. Like we often work with roller conveyors to move boxes. A box has certain data (in the PLC and in the database), but it can be positioned on different physical devices: long or short rollers, chains, crossings, turn tables, elevators, ...

I've seen attempts to try and get this all into one "generic" template, with a lot of flags (hasNoRoller, isHorizontal, isChaine, ...). And ultimately, this always fails because every new project has some type of roller you didn't think of. And every new developer using the template wonders what some parameter is.

What I prefer is creating multiple simple templates. One with just the bare box (that shows the box data and has the click handlers), and multiple templates with the different combinations. If you need a new visualisation for a new type of roller, it's easy to create as all the special box visualisations and code can be reused. And for adding the templates you just have to pick the right one from the tree.

• 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

UDT's are great for structuring tags. They allow you to easily define common alarms, historian settings etc, while still enabling you to make exceptions to those settings.

However, I don't like them for template parameters. The only advantage they have is drag-and-drop support. For all other purposes, they are very inflexible. When you work with tagpaths, it follows more the Python "duck typing" philosphy. If whatever you pass has the expected structure underneath, it will work.

You can work with complete tag paths, or with parameters that just encode a part of the path. I like to give the complete path, as otherwise you're again limited to the expected tag structure.

• 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.

Yes, the best structure is a top-down structure, where a template works stand-alone, and can be used in different other templates or windows.

• 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.

Passing on full queries is a no-no for me. It's way better to pass on the data in that case (and bind it to a query where you use the template). Passing parameters like table and column names still seems a bit iffy to me. But it can happen when you don't have full control over the database structure. Passing values to filter on (date ranges, device ids, ...) is what I would prefer. Then you do need to keep the template and the database design in sync, but that's easier than trying to predict how it will evolve and parameterize those things.

Certainly in Ignition 8, where you can easily make project-specific versions of existing templates, there's no reason to have a big number of parameters.

• 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.

If templates aren't too big, it doesn't matter where it's coming from. It's always easy to find.