yeah, pass that dict as a single payload (ideally, as an object, so you can validate it)
May I ask why you're storing things in tags ? Is that data used somewhere else ?
It looks kinda funky to pull data from a database in to tags, to then use these tags to send the data to an API.
What happens if another user runs the same process while the first one is still picking his 4 tags ?
1 Like
They are all client tags, so there's only one user per client session, and each user is working on one order at a time. I use tags to store the values because the screen includes labels that give the user visibility into the order details. The labels are bound to the tags, so when the user enters an order and the tags are updated, the labels update automatically.
Technically, I could just set the label values directly without using tags, but I remember reading in the forum that using client tags for this kind of temporary UI data is considered good practice.
I've read this forum a lot and i've never seen this advised. Sounds like over complication to me...
I'd pull everything in a dataset, bind a table ti it to display what's been retrieved from the db, add the 4 additional rows to it with system.db.addRows, then pass the dataset to the function that builds the dict.
2 Likes
Displaying a table to the user isn't consistent with how our applications are designed. We present data in individual labels, sometimes using different formats; for example, we show the number of completed serial numbers on a large LED display. I understand that loading everything into a dataset would be simpler from a development perspective, but we're aiming for interfaces that are user-friendly and tailored to the operator.
I think I’ll start a new thread to ask what the best practice is for this kind of application.
Using client tags in this fashion is a perfectly appropriate UI choice in Vision. Particularly if the flow of the UI opens a series of main windows that reference partial results. Exactly the same way one would use Perspective session properties to hold state in a multi-step UI.
I think you are just fine, Check.
1 Like
Thank you, @pturmel! Here is the general approach. Please let me know if anything is missing or could be improved:
- The user scans the order number.
- Ignition retrieves order details from the database.
- The order details are loaded in client tags which are bound to different components on the screen.
- The user sees the order details because the components were updated through the bindings.
- The user makes a few selections, wich are stored in other client tags.
- When done, the user clicks on a button to complete the transaction.
- The button reads the tag paths and sends them as a list to a function in the project library.
- The function reads the tags, builds a dictionary, and sends it as the payload to the API.
All reasonable. If it all one window, you could probably do the whole thing in window custom properties, which would allow a single user to work on more than one of those at a time.
But your architecture allows you to split the one window into multiple steps, each of which references the client tags it needs. Then the final save gets everything from those client tags.
I'd keep it as is.
3 Likes
It's a digression, but just for the sake of it - just because the data is in a dataset doesn't mean you have to display it in a table. You can bind your labels to a dataset just as well as you can to a tag.
In very recent versions of 8.1 you can also have a custom property of "document" type, which is effectively a JSON object.
My personal preference, with the hefty disclaimer that I've never had to maintain a Vision project professionally, would be to keep data to the minimum "scope" possible. That is, to prefer custom properties (in whatever form) in this case over client tags, just to minimize the chance of something else down the road interfering with (or subtly relying on) your client tags, until/unless you need the flexibility of a multi-window approach and need to share the data. But I would agree with Phil that if you've already got something working/close to working, it's not worth the effort to "refactor" it eagerly unless you've got an abundance of free time 
5 Likes
The current version of our application reads from the database and loads the values directly into the components on screen without using tags. In the new revision, I'm adding an API call. Would it be considered "correct" to continue keeping the values in the components without using client tags or custom properties? We don't need multi-windows because the operation is straightforward: the user scans and order, sees the details, makes a few selections, and completes the transaction. We do have multiple clients, but each client handles only one order at a time.
Client tags are not needed here. They are really used if you need user specific values to be saved across windows. Since your application is simple enough that isn’t needed, I would do everything I could to minimize my data footprint while keeping the processing as simple as possible.
In other words, don’t waste the time/effort to move the data to and from tags, when you can just as effectively keep it as is.