Best practice for embedded view data and DB updates

[mdemaris]

Hi everyone,

Imagine, if you will, you have almost 20 of these as embedded views:

At this time, each row of components, a total of 3, represent a record in a table, yes, there are duplicate values (e.g. the name "CZ01", and the last two check box values are recorded on each row).

Now imagine that every month or so a new set of records is created, so you end up with a list of basically blocks of data. I created this table just to show the list of blocks and if I click on a row (only one exists atm) the app navigates to a view with the above view displaying the data...

So, my user needs to be able to edit over 20 data points in each of these embedded views. So far that's not too bad. BUT, my current challenge is saving the changes to allow for one of two choices: update the current data block OR save a new data block.

In this case each block of data is represented by a VentID number, so in the example, almost 60 rows are identified with a VentID of 1 through 5.

Currently, the embedded view (speaking as if it's, um, independent of the main view at this point), have custom props for the data for itself - which is a parameterized query based on the value I assign it on the main view, 1 - 20 for example.
Then, I have a half-mile long list of custom props on the root that allow for changing values, colors and checkboxes as the user makes changes in the browser.

Here is a better example with real data: I picked two zones to display, have to hide sensitive info...

If I understand how to get data from embedded views (read from another post), I would need a parameter that each component could "save" to, so that a Button on the main view could grab that data, push into a query and run it.

OR, perhaps I could send a message from the Button click event, that the embedded view(s) could run a query on their side?

Any ideas or experience with something like this?

[Transistor]

It doesn't sound like there's going to be a good user experience no matter what you do. I would start again with a proper structure and sequential flow to operations.

[mdemaris]

Could you be more specific regarding a proper structure and sequential flow to operations?

[Transistor]

I can't quite figuire out what you're really trying to do. It looks like some kind of production / batch recording system with all input by the user (rather than, say, OPC tags).

It seems to me that you should be able to record all the information in one table with the date, batch number ("CZ05"), "5-1" number, sub-table row number (1, 2, 3, ...) and then the data.

A Perspective Table could then list the batch reports and use the table's subview capability to expand to show the individual zone reports.

https://docs.inductiveautomation.com/display/DOC81/Displaying+a+Subview+in+a+Table+Row

Then you could allow edit-in-place.
The half-mile long list of custom props sounds like another design issue.

Other considerations:
Is the data forever editable / never editable (once submitted) / something else?

[Tim_Carlton]

@mdemaris

be more specific regarding a proper structure and sequential flow to operations

Describe what the user wants to do from their perspective.

There are probably multiple users - operators, engineers, managers.
Each of those wants to do different things at different times.
Maybe one screen can do it all, maybe putting everything on one screen is too much.
There are different ways to approach this (or different names for it): storyboarding, use cases, user stories, etc.

[mdemaris]

@Tim_Carlton

Describe what the user wants to do from their perspective

I am designing a digital version of what the user does on paper, spending hours at a time. He makes semi-permanent changes in Excel. This edit, save, print cycle repeats four or five times every few weeks. (So the data is editable, until a new "batch" is made.) He is not computer savvy, so I'm hoping to make it as easy for him as possible with a familiar layout.

@Transistor

(rather than, say, OPC tags)

No tags used here. This is all CRUD, basically, by the user, talking to the DB. I come from using MS Access and am used to using record sets that I can easily connect to and map components to (or assign values), which means that I'm still green when it comes to getting data to and from components with some complexity. (I am only using one table in the DB to store all the data, along with some lookup queries to display a "Material" name instead of a number, for instance.)

To extrapolate on the batch idea: each batch of data is identified by an Event ID (represented as VentID (foreign key) in the table shown above), and the date it was created. Here are three records that show some of the info for CZ05:

The picture below graphically represents the relationships of CZ05/06 and the "5-1" numbers:

Each of the smaller blocks represent a row in the table.

I took a look at the subview idea, and I'm not really sold on using it here. I don't like the "dropdown" feature on each row, that would be extra clicks for the user to see all the data at once.