Date validation refactoring?

[Uncle Buddy]

I'm most of the way finished writing the code that will input new events. All was well until it came to melding with the existing date validation process. The dates module is 2000 lines of very old code that's already been refactored at least twice. By "very old" I mean this was one of the first things I did when I started using Python. I finally got it to work, but it was meant to be used only with a certain type of widget, which I call EntryLabel. This is a Label that displays dates and other data in the events table and a few other places. When you click in it or when it gets focus, it turns into an Entry and you can edit what was there or add data if the Label was empty before.

EntryLabel is a good widget but the problem is that my complex date validation was designed to be used only with this widget. So the dates module is now inflexible code that I will have to hack into in order for it to handle data from other kinds of widgets. This can be done but there are other problems lurking in this ancient code. I'm still a beginner, but not the kind of beginner I was two or three years ago when I wrote this validation procedure, then rewrote it, then changed it to a class, then rewrote it some more...

Truly I believe that it's time to take advantage of my experience as a more advanced beginner and rewrite the code from scratch. The way to write a date validator, I believe today, would be like this:

Why make it a class? Each procedure is working with one value. That value can be passed to the next procedure. A validation procedure is not an object, a noun; it's a verb. A process. The date validator should start with a string input that can come from any kind of widget. Each process that has to be performed on the evolving date string should return a value so that each procedure is called by the next procedure, the procedure that needs that value. One problem with the code I already have is that, since it's a class, it has all these instance variables which--like global variables--can be changed from more than one place. The code gets confusing because you might have to trace through to figure out where something is getting changed.

I avoided classes for a long time, till I learned how to use them, then I overdid it and converted almost everything to a class. No harm was done but some things might have to change. I will have to make a test module and rewrite the code one line at a time so I can test it with any string gotten from any widget that can hold a string value.

The hardest part of the existing date validation code to write was for compound dates such as "from 1885 to 1899" or "between 1789 and 1802". Two dates have to be validated separately, and with all those instance variables bouncing around and certain parts of the code being run twice, it got confusing. This time I will treat every date as if it was a compound date so that the compound date doesn't have to be treated as an exception. Not sure how that'll go but I do want to avoid the confusion of having the exceptions be so complex compared to what I set out to tackle when I first wrote the first version of the validator.

Similar problems are just now cropping up with another edge case, the ambiguous date. Treebard will accept date parts in any order, because my experience with date input on other applications is that it's always annoying and every application has different rules for how to format your input. In Treebard, you can type 2 14 1810 or 1810 2 14 or 14 1810 2 etc., and Treebard will figure out which one is the day, which one is the year, and which one is the month. This example is obvious but a clarifier will pop up to get more user input in a case like 1810 12 9. The user will have to tell Treebard which is month and which is day between the two values < 13. Once again the clarifier procedure was working great (aside from being written and patched and fixed and patched) until I tried to apply it in a unique situation. This code is a no-grow. So my new plan is to treat every date as if the clarifier will be needed and then bypass it if it's not needed. Somewhere along the way I heard that edge cases should be handled first, which kinda prevents the scenario of waiting till something goes wrong and then plugging the dam with a spare finger. When you run out of fingers, the code is officially unextendable.

I'll bet anything my date validation procedure is a good example of brittle, easily broken, not easily extended, unadaptable spaghetti code that needs to be done over completely. Do I want to spend the next week proving that to myself and get a big headache, or start over now and save myself that week?

The main reason I say this is that secretly bad code (which has been working great for a long time) reveals its tangled nature only when you try to finish something else and the something else can't be finished because the old code isn't adaptable to unexpected interactions. Trying to alter or extend the old code then takes days and ends up becoming a matter of patching this to break that and fixing that to break two other things which then have to be patched. With each improvement being like pulling one of your own teeth. Better to start over, trusting that my current experience will lead me to simpler solutions and it will all be over sooner, with better results, than if I were to spend the next several days banging my head against a giant mountain of molding spaghetti.

[Uncle Buddy]

Refactoring of the dates validation procedure is underway and I'm relieved that I've finally taken this step. It will mean some refactoring of other code that's dependent on the older, more convoluted dates validation procedure, but it's needed anyway.

It just occurred to me that I was well aware, while writing the old dates validation module, that a large proportion of the work I was doing was to accommodate edge cases, for example, the tiny percentage of genealogists who would be using dates with less than four digits. Prior to the year 1000. Wanna know who was living at the site of your grannie's farm in the year 8? I think his name was Fang. But Treebard was still gonna accommodate some imaginary genealogist's need to type the year "8" as "8" instead of "0008". Lots of code was written to make this easy for every user. None of whom were gonna turn cartwheels in the aisles because of all my extra effort.

That user who would reject Treebard for not letting him type the year 8 as "8" probably doesn't exist, so the current refactoring is taking a different approach. Instead of letting the user type "8 12 4" and then writing code to pop up a clarifying dialog so Treebard can be told which is the year, which is the day, and which is the month, Treebard is now gonna insist that all years have four digits. So it's "0008", or else what pops up for that rare researcher of primordial families will be an error dialog.

I'd wanted to give the user a lot of flexibility as to how a date can be entered when I started this project. This is still my goal. But allowing input like "1900 10 11" was again going to require a clarifying dialog to pop up. This is not the kind of flexibility users want, and it's no longer the kind of code I want to write, now that I've proven I can do it. The best way to input dates is like this: "1892 3 ap" in any order. The part I'm still devoted to is "any order". Months input as numerals are a no-no from here on out. This is not only gonna save me a lot of complicated coding, it's gonna save the user from having to answer questions on a pop-up dialog. As always, there will be some flexibility as to how the dates display, but in Treebard the way you enter a date is unrelated to the way it displays. You enter the date in a very simple, easy way and it will display however you told it to display, according to your preference settings.

I'm sure this whole date validation process is available from any number of importable Python libraries as a finished product, but I'm having so much fun learning how to do this stuff myself, and how to make design decisions, why would I want to restrict myself to someone else's way of doing things? At this point I still prefer to make my own mistakes whenever possible instead of importing and (worse) installing dependencies. The only library I've installed so far is the Pillow library for images, and fortunately the recent versions of Python can now install this library for you with no muss and no fuss.

But dates validation? I can do that myself, with the result that the code will be understandable and maintainable by me.

What's the big deal?

Well I've attempted to use many genieware apps and often run into GUI booby-traps where I'm forced to input a date in some exact format that I have to memorize, with the year/month/day in some certain order and the right separator between them. Or worse, I try to type into a date field and a calendar pops up so I can fiddle around trying to find the right month and year and pick dates with a mouse. This is slow and cumbersome. I've encountered genieware GUIs whose date fields were so non-functional as to send me packing after five minutes of trying to discover an intuitive workaround of the GUI designer's lack of concern. Designers of genieware need to concern themselves with this: genealogy is fun. If data entry spoils the fun, the lowest-common-denominator genieware substitutes available down at Genealogists-R-Us.com will continue to monopolize this otherwise enjoyable hobby.

I could have just written a blog about what's wrong with existing genieware but it's more fun and hopefully more productive to try to write code that demonstrates better, more intuitive, easier-to-learn functionalities. So I'll get back to it.