Finishing the latest rewrite of the families table
May 23, 2024 17:47:57 GMT -8
Post by Uncle Buddy on May 23, 2024 17:47:57 GMT -8
The nuclear families table or families table is above the events & attributes table on the left, on the persons tab. It shows four types of person: the current person's parents, partners, children, and alt parents such as foster parents, adoptive parents and guardians. For the children it also shows their birth and death dates. Every row in the table is sorted by a child's birth date or a couple event date, if one is available.
Previously I had added an overlay edit widget so the user had to double-click a table cell to edit it. I've just changed that to directly use the autofill widgets for names and plain inputs for dates, with the usual date validation which lets the user input dates very freely and then displays the date, after validation, according to the user's selected format options. Like the recently rewritten events table, the user now can just tab or click into a table cell and start typing. Code detects changes to what was in the cell on FocusIn, and edits are saved immediately to the database on FocusOut from the cell. There is no SAVE button, the user never has to save anything.
This 3rd or 4th rewrite of the families table has gone smoothly, and the basics are done. It looks the same as before and works better. The new kintips were already working independently, there is no longer any rigid connection of the code between the kintips in the events table and the people in the families table, so changing code in one place has little effect on the other. In other words, when I finished the display code for the families table, the kintips in the events table still worked. A pleasant surprise.
The four types of people in the families table are saved in four independent collections of data. No more scary nested collections to make everything else hard. Nesting of data in collections is useful but it's not the only way, and in my case it had become something I was doing because I could. Not a good enough reason. It had led to dissimilar things becoming conglomerated into one place. This makes the code hard to work on as it makes the mind want to draw invalid conclusions about what is supposed to relate to what, while trying to read the code.
Which brings me to the part where the four types of people each have to be editable in five ways, as shown in the mocked-up table below. The real table in the do-list doesn't have 20 Xs in it yet.
When the real table in the to-do list has 20 Xs in it, the feature is finished again. The code for this already exists but it all has to be adjusted since the data collections and the input widgets have been greatly simplified.
It's 9:55 a.m. on Friday May 24, Manila time. Will it take an hour to finish this feature? A day? A week? I'm curious to find out.
Previously I had added an overlay edit widget so the user had to double-click a table cell to edit it. I've just changed that to directly use the autofill widgets for names and plain inputs for dates, with the usual date validation which lets the user input dates very freely and then displays the date, after validation, according to the user's selected format options. Like the recently rewritten events table, the user now can just tab or click into a table cell and start typing. Code detects changes to what was in the cell on FocusIn, and edits are saved immediately to the database on FocusOut from the cell. There is no SAVE button, the user never has to save anything.
This 3rd or 4th rewrite of the families table has gone smoothly, and the basics are done. It looks the same as before and works better. The new kintips were already working independently, there is no longer any rigid connection of the code between the kintips in the events table and the people in the families table, so changing code in one place has little effect on the other. In other words, when I finished the display code for the families table, the kintips in the events table still worked. A pleasant surprise.
The four types of people in the families table are saved in four independent collections of data. No more scary nested collections to make everything else hard. Nesting of data in collections is useful but it's not the only way, and in my case it had become something I was doing because I could. Not a good enough reason. It had led to dissimilar things becoming conglomerated into one place. This makes the code hard to work on as it makes the mind want to draw invalid conclusions about what is supposed to relate to what, while trying to read the code.
Which brings me to the part where the four types of people each have to be editable in five ways, as shown in the mocked-up table below. The real table in the do-list doesn't have 20 Xs in it yet.
| PARENT | ALT PARENT | PARTNER | CHILD | |
| change existing person to existing person | X | X | X | X |
| change empty cell to existing person | X | X | X | X |
| change existing person to empty cell | X | X | X | X |
| change existing person to new person | X | X | X | X |
| change empty cell to new person | X | X | X | X |
When the real table in the to-do list has 20 Xs in it, the feature is finished again. The code for this already exists but it all has to be adjusted since the data collections and the input widgets have been greatly simplified.
It's 9:55 a.m. on Friday May 24, Manila time. Will it take an hour to finish this feature? A day? A week? I'm curious to find out.