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

General Discussion
43

LOL. I do that so that I can easily recognize what type of component it is. But, I use underscore like so: lbl_Title

1 Like
44

This is a great post with a lot of helpful tips. Any level of experience could learn something from this post. I wanted to share this thread with newer developers but wanted it a bit better organized. Thanks to the help of my make-believe assistant, I was able to do this relatively easy! :smiley: Wanted to share the output here too.

I take no credit for this knowledge.

1. Naming, Folders & Structure

  • Don’t be scared of making folders; navigation is key—better folders than a mess of files.
    credit: @danielps1818

  • Give inputs names that match their purpose; container names should describe contents (Top/Bottom/Left/Right, Header/Footer) to ease view-tree navigation.
    credit: @Ryan_Deardorff

  • Fixing container/component names can break views that don’t use #13.
    credit: @pturmel

  • Aim for Jython-friendly naming: avoid spaces and be careful with non-alphanumeric characters.
    credit: @msteele

  • Build tag paths that are concise, human-readable, and meaningful.
    credit: @msteele

  • Folders can have custom properties (not visible in Designer) and can be written via system.tag.writeBlocking() or tooling.
    credit: @msteele

  • Document your naming/folder conventions so others (and future you) can follow them; consistency matters more than perfection.
    credit: @Brandon_Peterson

  • “FlexContainer_0”… if you follow that pattern, remember to increment.
    credit: @msteele

2. Scripting Architecture & Reuse

  • Put event logic in the scripting library; event/tag/property handlers should be one-liners that call library functions.
    credit: @bkarabinchak.psi

  • Reasons: version-controllable/diff-able; easier to test via script console; decorators (e.g., @timeAndLog) add cross-cutting features without editing every event; reusable; avoids old scoping issues.
    credit: @bkarabinchak.psi

  • Prefer a base parent project for reusable code over copy-and-paste.
    credit: @Ryan_Deardorff

  • Reuse aggressively (imports/exports, reusable classes); think about the next project—but note that “global” variables and heavy abstraction can introduce errors.
    credit: @danielps1818

  • Beware over-abstraction: it’s OK to duplicate views (e.g., create vs. edit) instead of forcing one to fit multiple roles; simpler and safer to change later.
    credit: @pascal.fragnoud

Example decorator:

@timeAndLog
def foo(*args, **kwargs):
    pass

credit: @bkarabinchak.psi

3. UI & Perspective (Bindings, Patterns, Animations)

  • Don’t push from tag scripts to UI; bind tags to UI properties to pull data, and place change-monitoring actions in the UI where needed.
    credit: @pturmel

  • Scripts are resource-heavy—use bindings instead (preferably without script transforms).
    credit: @pturmel

  • Simple property bindings are fastest.
    credit: @pturmel

  • Tag and named-query bindings are asynchronous; reference them with simple property bindings instead of curly-brace tag refs or scripted queries.
    credit: @pturmel

  • Expression bindings are faster than scripts; if you must script in a binding, runScript() in an expression binding is faster than a script transform.
    credit: @pturmel

  • Avoid the tag() expression function “like the plague.”
    credit: @pturmel

  • Don’t use scripts for Perspective animations—use CSS/style animations.
    credit: @victordcq

  • If something seems “impossible” in Perspective, ask on the forum; CSS/JS injection workarounds may exist.
    credit: @victordcq

4. Scope (Gateway vs Client)

  • Schedule/house server-side tasks (e.g., 5 AM resets of DB tables/tags) in the gateway scope—not client—so they run even if clients are closed and to avoid N× duplication across many clients.
    credit: @bkarabinchak.psi

  • Inverse: don’t use gateway tags to track client UI state; use client tags/session props.
    credit: @bkarabinchak.psi

5. Database & Queries

  • Get DB design right: correct data types (don’t store dates as strings); use named or prepared queries; use transactions; ensure uniqueness via a proper PK or UNIQUE index.
    credit: @bkarabinchak.psi

6. Tags, UDTs & Tooling

7. Process & Community

  • Document conventions so you can iterate and improve across projects.
    credit: @Brandon_Peterson

  • If people say it’s impossible, tag experts for workarounds.
    credit: @victordcq

3 Likes
45

I don't find a wall of mostly bold-face text to be "better organized". Not to mention that you omitted all of the reference links. LLM output is generally not welcome here on this forum. See the FAQ for details.

5 Likes
46

Do you have suggestions on how it could be organized for newer users? For instance if they wanted to improve their UI.

Maybe not the end all best way to bucket the tips but it was quick way to get a first iteration.

47

You mention a couple of mine, but not the one I feel strongest about (#13). It can save so much time and hassle when rearranging components. So much so that I feel like Ignition should never have allowed custom properties on anything but the view, and made each component’s props only visible to itself.

4 Likes
48

Yes, read the whole topic, follow the links. The topic itself is a bunch of summaries. Re-summarizing is lossy.

Newbies using LLMs with Ignition is a good way to waste time and get in a bind.

5 Likes
49

Agreed on having a newbie avoid LLMs all day. This came to mind after talking to someone about how data flows through a project, and wanted to give them community driven tips. They’re some in here but in between heaps of other good tips.

Using this thread as the dataset for the LLM to paraphrase from I felt a bit better about myself. I also don’t like how it has the reply links omitted not allowing one to easily see more context. Was interesting to have this as a use case and see the result.

50

Most of this has been covered already other’s posts but I thought I’d write up some mistakes that happened on the first project I inherited and had to fix up.

  • Complex bindings - passing objects (key1) to embedded views rather than simply values. At first it seemed fine until the project grew and bandaid fixes would add more sub-tags to key1 and then perspective started to not always display the correct objects. A lot of rework was done to only pass simple values like tagpath into the object and then move any additional info into the UDT itself.
  • SQL - We had some niche requirements that needed custom database tables made to store certain things we couldn’t save into tags. During early development it was never considered that clients on gatewayA won’t have a network path to the database connected to gatewayB for cybersecurity reasons. Took a fair bit of re-work to break up how things were done, moving some into tags and some into remotely executing named queries with message handlers. In hindsight I would’ve pushed back on the project requirements to simply just not agree to do certain things.
  • Too many embedded views, not necessarily related to point 1 but rather just making every little widget it’s own view but often times some of those widgets were only ever used in one place. This meant for maintenance you had to constantly jump around the project to find where you could make a change. Use embedded views when it makes sense or they’re recycled but don’t needlessly use them and create clutter.
  • Be mindful of choices when laying out tag / folder structures. Objects like tagbrowser or powerchart use those structures so it’s important to make things clear and consistent from the very beginning as operations will see it down the road.
  • Make better use of session.custom properties and not always rely solely on view.custom.