Getting Input from the Events/Conclusion Table
Mar 30, 2020 22:43:36 GMT -8
Post by Uncle Buddy on Mar 30, 2020 22:43:36 GMT -8
I'm starting a new code module to deal with inputting new data to the database from the events table, which is the main tab in the app, also known as the conclusions table. As discussed elsewhere, events and assertions are kept separate-but-linked in Treebard. Conclusions are entered by the user directly, with or without linking assertions which have to be sourced. So I'm making design decisions right now about how this will be done, especially how often to send data to the database.
In databases, from what little I know, info is saved continuously. I've even been told that the Save button on some applications might be there only to reassure the user. On other applications, the data might be stored in the front end for a period of time and sent to the db periodically. But there's a limit to that sort of thing because if you enter Martha's father right now, you want his info to be available almost immediately so you can add to it or query any effect it might have on other data.
It seems excessive to insert to db on each focus out bec. there's only one cell of each type on each row, so it would be like making a dialog modal when not necessary. The developer wants common sense to to prevail, but it's not always his problem. At some point it has to be possible to enter anything you want and let the user make his mistakes. The kind of validation done with dates is not desirable with names. Places is a different story, that comes last. Bad place names are a big problem, like bad dates.
However there is an exception to what I just said about cells on the same row. Date and age are inextricably linked, but other programs let you enter either one or the other and you can even enter conflicting data on the same row. To prevent this, you could for example make it impossible to enter data in both date and age. But in applications other than Treebard, that might be wrong, because if the source has both, then both should be entered as found, even if wrong. However in Treebard the conclusions table, where the user makes his own decisions, is not the assertions table, where the sources are recorded exactly as found. So where should I draw the line on enforcing consistency on a single event?
The cell should still become readonly upon focus out. But there should be code to tell when user has focused out of the ROW and only then the data from the whole row will be input to db if any of it has changed. Which is another good reason for readonly because user can tab through readonly widgets without triggering a hit on the db. To trigger input to db, user has to type into a cell which means he has to dbl click the cell if it already has something in it. This will prevent frivolous hits to the db caused by meandering over the page with the tab key, random clicks of the mouse, etc.
Possibly the Save button or Ctrl-S feature should be able to read text in every cell in the app's open windows and save anything that has changed from what's already in the db. Obviously this function would be called for any window as it's being closed.
About entering both age and date. Treebard does not allow conflicting conclusions. The reason other programs allow more than one birth event, for example, is that they don't separate conclusions from assertions. The result is mud, annoying to look at and unrevealing to behold, especially when looking for a useful summary which is what the events table is supposed to be, not a hodge-podge of conflicting and redundant claims. Multiple copies of the same event on the conclusions tab are grotesque, a big turn-off, made necessary because conclusions and assertions are treated the same. For example, you'll see entirely redundant info in trees such as birthdate 1845 and birthdate Nov. 1845. This isn't the user's fault. He's got a source for each, and he's trying to keep track of his sources accurately. This can't be done without ugly, redundant, nearly identical entries of different versions of what is essentially the same date, under the status quo system in which everything is a conclusion.
Treebard keeps track of assertions separately, inextricably linked to sources, one source per assertion. From there (or skipping sources entirely if desired) the user enters conclusions separately on a separate tab and can link his conclusion to a source if he wants, or many sources, or no sources. Since assertions MUST be sourced while conclusions CAN be sourced, what happens is that there is a comfortable place to sit back and say, "This person was only born once." There will be one copy of each event on the events table, with possibly several copies of the same event backing up that one event as assertions. The disagreement over what really happened is shown clearly on the assertions tab. This disagreement must not be carried over to the conclusions tab. It would ruin the whole purpose of Treebard's slogan "evidence-assertion-conclusion". There's a Sources button on every event row so the user can check his basis for any conclusion with one click of the mouse.
Therefore I've decided that age and date fields on the events table (conclusions) are not both available. This prevents the user from entering conflicting data as a conclusion. Conflicting data must be sourced and entered as separate assertions.
If the user enters a date, the age will be calculated and shown as such. If he enters an age, the date will be calculated and shown as such. If he enters a date he calculated himself and then tries to enter an age he knows to be factual, and can't, then he can delete the date he calculated himself, enter the known age, and Treebard will calculate the date so as to not conflict with the entered age. And vice versa. If the user doesn't like this, he can change his conclusion to get results he can agree with. If this isn't possible, maybe he's trying to form a conclusion prematurely. But entering conflicting data in a single row can't be allowed. That's why it's called a "conclusion". If a conflicting age and date are allowed on a single row, it will cause problems down the line and bloated code will then grow like the lie that had to be backed up by a hundred more lies.
This will not force the user to make an inalterable decision about when a person was actually born, because other events will not be dated accordingly in the conclusions page. One row's date will be consistent with that row's age, due to strict validation and calculation. But to enforce this all up and down the events table would wreak havoc due to the fact that one person, especially in the old days, collected a number of different birth dates, especially birth years. I even have a case, reported on this blog, of a man who kept two different birth dates his whole life, registering for the draft separately under both birth dates and marrying the same woman twice. Imagine if the events in his life were forced into some mold to satisfy some smarty-pants software when the truth about this guy is so much more interesting; when in fact the documents we can track him with lend equal credence to two wildly different birth dates.
But on a single event, it would be wrong to allow conflicting data. If this doesn't work in practice, I'll repeal it, but I'm gonna try to make it work this way.
In databases, from what little I know, info is saved continuously. I've even been told that the Save button on some applications might be there only to reassure the user. On other applications, the data might be stored in the front end for a period of time and sent to the db periodically. But there's a limit to that sort of thing because if you enter Martha's father right now, you want his info to be available almost immediately so you can add to it or query any effect it might have on other data.
It seems excessive to insert to db on each focus out bec. there's only one cell of each type on each row, so it would be like making a dialog modal when not necessary. The developer wants common sense to to prevail, but it's not always his problem. At some point it has to be possible to enter anything you want and let the user make his mistakes. The kind of validation done with dates is not desirable with names. Places is a different story, that comes last. Bad place names are a big problem, like bad dates.
However there is an exception to what I just said about cells on the same row. Date and age are inextricably linked, but other programs let you enter either one or the other and you can even enter conflicting data on the same row. To prevent this, you could for example make it impossible to enter data in both date and age. But in applications other than Treebard, that might be wrong, because if the source has both, then both should be entered as found, even if wrong. However in Treebard the conclusions table, where the user makes his own decisions, is not the assertions table, where the sources are recorded exactly as found. So where should I draw the line on enforcing consistency on a single event?
The cell should still become readonly upon focus out. But there should be code to tell when user has focused out of the ROW and only then the data from the whole row will be input to db if any of it has changed. Which is another good reason for readonly because user can tab through readonly widgets without triggering a hit on the db. To trigger input to db, user has to type into a cell which means he has to dbl click the cell if it already has something in it. This will prevent frivolous hits to the db caused by meandering over the page with the tab key, random clicks of the mouse, etc.
Possibly the Save button or Ctrl-S feature should be able to read text in every cell in the app's open windows and save anything that has changed from what's already in the db. Obviously this function would be called for any window as it's being closed.
About entering both age and date. Treebard does not allow conflicting conclusions. The reason other programs allow more than one birth event, for example, is that they don't separate conclusions from assertions. The result is mud, annoying to look at and unrevealing to behold, especially when looking for a useful summary which is what the events table is supposed to be, not a hodge-podge of conflicting and redundant claims. Multiple copies of the same event on the conclusions tab are grotesque, a big turn-off, made necessary because conclusions and assertions are treated the same. For example, you'll see entirely redundant info in trees such as birthdate 1845 and birthdate Nov. 1845. This isn't the user's fault. He's got a source for each, and he's trying to keep track of his sources accurately. This can't be done without ugly, redundant, nearly identical entries of different versions of what is essentially the same date, under the status quo system in which everything is a conclusion.
Treebard keeps track of assertions separately, inextricably linked to sources, one source per assertion. From there (or skipping sources entirely if desired) the user enters conclusions separately on a separate tab and can link his conclusion to a source if he wants, or many sources, or no sources. Since assertions MUST be sourced while conclusions CAN be sourced, what happens is that there is a comfortable place to sit back and say, "This person was only born once." There will be one copy of each event on the events table, with possibly several copies of the same event backing up that one event as assertions. The disagreement over what really happened is shown clearly on the assertions tab. This disagreement must not be carried over to the conclusions tab. It would ruin the whole purpose of Treebard's slogan "evidence-assertion-conclusion". There's a Sources button on every event row so the user can check his basis for any conclusion with one click of the mouse.
Therefore I've decided that age and date fields on the events table (conclusions) are not both available. This prevents the user from entering conflicting data as a conclusion. Conflicting data must be sourced and entered as separate assertions.
If the user enters a date, the age will be calculated and shown as such. If he enters an age, the date will be calculated and shown as such. If he enters a date he calculated himself and then tries to enter an age he knows to be factual, and can't, then he can delete the date he calculated himself, enter the known age, and Treebard will calculate the date so as to not conflict with the entered age. And vice versa. If the user doesn't like this, he can change his conclusion to get results he can agree with. If this isn't possible, maybe he's trying to form a conclusion prematurely. But entering conflicting data in a single row can't be allowed. That's why it's called a "conclusion". If a conflicting age and date are allowed on a single row, it will cause problems down the line and bloated code will then grow like the lie that had to be backed up by a hundred more lies.
This will not force the user to make an inalterable decision about when a person was actually born, because other events will not be dated accordingly in the conclusions page. One row's date will be consistent with that row's age, due to strict validation and calculation. But to enforce this all up and down the events table would wreak havoc due to the fact that one person, especially in the old days, collected a number of different birth dates, especially birth years. I even have a case, reported on this blog, of a man who kept two different birth dates his whole life, registering for the draft separately under both birth dates and marrying the same woman twice. Imagine if the events in his life were forced into some mold to satisfy some smarty-pants software when the truth about this guy is so much more interesting; when in fact the documents we can track him with lend equal credence to two wildly different birth dates.
But on a single event, it would be wrong to allow conflicting data. If this doesn't work in practice, I'll repeal it, but I'm gonna try to make it work this way.