Hypothetically, this problem will arise when there are two users trying to add/edit the observations at the same time. So, right now, the idea behind the saving function is this:
When we get the data from the server, we sort it so that the latest entry comes first.
Then, we populate the editTreeView page, with the sorted list of entries.
Now, the tricky part is, how can we know what entry is being edited? Or being added? Formerly, this is done by finding the index of the row (vis-à-vis the HTML table) currently made editable, and matching the index with the Tree model's diameter object. However, this is complicated by the fact that we can sort the entries vis-à-vis other fields of data (e.g., we can sort it by observers). This means that the order of the observation entries (i.e., the diameter attribute) in the Tree model will not necessarily match the order of those in the HTML table, making impossible to identify what tree we are currently editing exactly.
To solve that problem, I added a class to each observation entry row, that tells us the index in the original Tree model (which is—this is a new function added recently—sorted vis-à-vis the observation dates). As such, no matter vis-à-vis what field of data the HTML table is sorted, each observation entry row will retain the information necessary to match it with its original in the Tree model.
Now, the problem is, I will need to create a new observation entries array that incorporates the newly modified data. When I save the Tree model on the JavaScript side, the server will completely replace the "old" observation entries array (i.e., the diameter attribute).
The subsequent problem that arises is, then, that the "old" observation entries array in the database is not necessarily "old." For example, what if A and B are both adding new entries at the same time but A submits his entries first? Since B has not been refreshing the page recently, B's Tree model will not know that A has just submitted new entries. And since the saving mechanism will replace the old array completely, in saving his Tree B will replace A's newly submitted data.
Hypothetically, this problem will arise when there are two users trying to add/edit the observations at the same time. So, right now, the idea behind the saving function is this:
To solve that problem, I added a class to each observation entry row, that tells us the index in the original Tree model (which is—this is a new function added recently—sorted vis-à-vis the observation dates). As such, no matter vis-à-vis what field of data the HTML table is sorted, each observation entry row will retain the information necessary to match it with its original in the Tree model.