Do's and Don'ts when developing First Project with Ignition?

General Discussion
1

Hi everyone, i am learning ignition to work on first project and want to know some tips/tricks to be careful while developing first project so i do it properly and organize tag structure, graphics etc in the proper way in my project ?

thanks for all your help
Regards,
Mitesh.

1 Like
2

Don't be scared of making folders.

In our team we didn't do it until it was too late and we had a tree that looked like this (and it was hell looking for anything):

Scripting
├ randomfolder
│ ├ class001
│ ├ class002
│ ├ class004
│ └ class003
├ randomfolder2
│ └ class18
├ class2
├ class4
├ class3
├ class5
├ class8
├ class10
├ class12
└ class7

Navigation in a project is key to efficiency and organization. Is preferable to have folders than a mess of files.

Also, I really recommend making templates so you could reuse views.

6 Likes
3

Put everything into the scripting library, all events, property changes, tag events, etc should be one liners that call a library script. Multiple reasons for this -

  1. your script library is version controllable/diff-able as it's plaintext.
  2. Makes it easier test your functions. If you put your whole script in a tag change function now the only way to test it is to change the tag, where if its a function you can make your params and run it in script console (assuming scope is ok).
  3. Decorate-able. If you you put all your logic in the event script then decorators will not really work for you, you have to manually change the script. But if a tag change event is calling foo and all of a sudden you want to start timing or logging stuff about your function now in your script library you can do a
@timeAndLog
def foo(*args, **kwargs):
    pass

and now all locations you call foo get this/you can use this decorator on any piece of logic you have.
4) as hinted to above now the script is reusable.
5) some old scoping issues that you will avoid if you do things this way.

Other tips about your project - get your database design right. Use the right data types for the right column types (ie do NOT use string to store dates), and use named queries or at least prep queries to run your inserts/updates. Use transactions and either make a appropriate primary key that truly determines a unique row, or if you are using an id primary key, at least create a UNIQUE index that will determine uniqueness of a row.

Last issue that comes to mind that I see a lot in the field is putting things in the inappropriate scope. If you have a function that needs to reset a database table or tag values at 5 AM everyday that should be in the gateway scope not the client scope for instance because if the client happens to be off, then it won't run, or if you have 100 clients now you're wasting resources/making things confusing by running it 100 times. Inverse applies here too - do not use gateway tags to keep track of things regarding client UI. That is for client tags/session props.

15 Likes
4
  1. Do not attempt to push information from tags to UI screens. That is, scripts reacting to tags should not be used to notify affected UI pages/views/windows/templates. Instead, bind those tags to UI component properties to pull the information into the UI, and write any change monitoring scripts/actions there.
  2. Scripts are resource hogs. Use them only for tasks that cannot be done any other way. In user interfaces, use bindings, preferably without script transforms.
  3. Simple property bindings are fastest.
  4. Tag bindings and named query bindings are asynchronous. When triggered by startup or a reference change, they do not hold up any other bindings. Use them, and reference them with simple property bindings, instead of curly-brace tag references or scripted queries.
  5. Expression bindings are faster than scripts, as long as you aren't using runScript().
  6. If you must use a script in a binding, runScript() in an expression binding is faster than a script transform.
  7. Avoid the tag() expression function like the plague. Because it is a plague.
18 Likes
5
  1. Bind UI input values to custom properties of the view, and reference those instead of the input value itself. It not only makes for cleaner code without a bunch of getChild/getSibling nonsense with hardwired component names, but ensures that you can reorganize and rename components without breaking those references.
  2. Name your UI components/containers. It may seem like unnecessary effort in the short term, but in the long term it will save lots of hassle when trying to navigate your way down to a specific component.
  3. Browse this forum regularly. I have learned many valuable tips just from reading responses to other people's questions.
16 Likes
6

:100:

(But don't shout.)

8 Likes
7

Honestly this is something that I always seem to ping pong back and forth on a good naming convention.

Coming from the VBA/RSView side of things... I automatically for the lblTitle, txtBoxInput type of thing.

Any good recommendations on naming? Or a standard convention that you use?

8

PascalCase, mostly. I absolutely despise those type-prefixed formats. See the Exchange style guide for more ideas.

9

I'm actively trying to shed that muscle memory...

So you tend to name things based on their purpose then? IE EntryMotorSpeed (numeric entry), ActMotorSpeed (label), things like that?

1 Like
10

(But don't shout.)

Yeah, that's the kind of frustration caused by leaving one's predecessor with names like "FlexContainer_0" :woozy_face:

7 Likes
11

Yes. If the purpose is served by a container of a label, entry, and button, the container will get the general field's name, and the inner components will be Label, Entry, and Button. For ease of reuse.

2 Likes
12

Gotcha... I've been doing the same lately as well, and when revisiting older stuff and a refresh.

I appreciate the pointers.

13

Be aware that fixing container and component names will break views that don't use #13.

2 Likes
14

I just try to give input names that match their purpose (like maybe the column name of the database entry its tied to). Containers can be as simple as Top/Bottom/Left/Right, or Header/Footer, but usually I try to describe their contents. I don't use the naming convention you mention, partly because I don't need to reference the input itself in my code (#13). The names mostly make it easier to navigate the view tree...

1 Like
15

I registered for ICC 2024 under this name. Anyone else following this pattern remember to increment.

11 Likes
16

Great thread with a lot of useful tips!

1 Like
17

If perspective and if something seems impossible, you have ask on the forum and people say its impossible, tag me (if i havent seen your post already).
I might have some work arounds with css and js injections... :mage:

1 Like
18

Dont use scripts to animate things in perspective, you must use css/style animations.

9 Likes
19

Re tag structures... one of the best things with our latest architecture was using folders reasonably. Some great advice we got:

  • Aim for Jython-friendly naming, mainly avoiding spaces and being careful with non alphanumeric characters.
  • Build tagpaths that are human readable and meaningful. Concise, but clear.
  • A plug for @pturmel's Spreadsheet Import Tool, which creates implied folders as it writes tags and UDT instances. This solves a common critique of UDTs being inflexible with their members.
  • Custom properties are your friend, and you can write these from within this tool for anything that needs to be unique but won't change over time. View paths and tag paths as custom property strings are quite powerful.
  • Related, check out the var map functions in the Integraton Toolkit module and let your mind lead you in creativity. I can't divulge my secrets but they depend on these var maps heavily.
  • Folders can have custom properties, even though you cannot see these in Designer (enhancement request?). But you can write to them via system.tag.writeBlocking() and via the Spreadsheet Import Tool.
3 Likes
20

Thank you everyone for all the tips and tricks. i will need time to go through and understand. may ask some question to clear my understanding on some of the point later. have a good day

1 Like