Update round I
Here we go, with the first update round for today.
New editor
I’ve switched to a new text editor - Programmer’s Notepad. It has a built in file explorer, a feature I’ve been missing from Notepad++. Programmer’s Notepad is comparable fast, and supports even more languages.
API progress
I’ve modified modules to support a one-time init()-call, which allows a module to perform static data initialisation. There has been also a lot of refactoring in the API, a new Utility class encapsulates much of the framework’s static functions. Moreover, a new ErrorHandler class provides a custom error handler that print backtraces in case of fatal errors. For some reasons, it does not work together with ADOdb yet, will have to investigate that further.
Frontend code
Much of the code that has been in the frontend files is now part of the API, and the remaining code is really just frontend code - data validation and preparation for the template engine. At the moment, most of the code is broken, but I’m working on it. I hope the bug report code will work again this weekend.
Misc changes
Versions and builds can be tagged as “released” now. Only released versions and builds appear in the report screen, all other are treated as milestone builds. I’ve created a JScript based version/build choose screen, where the user selects the version first and is allowed to select a valid build or none, in case the exact build is unknown. Looked quite simple, but the JScript code turned out to be rather ugly (for example, I’m clearing the build select field using b_select.innerHTML = '' as there is no clear() function for the OptionsCollection). I really don’t like it, but as it does its job, I’ll keep it in. The alternative would be to add yet another page to the Bug Report Wizard, but I don’t want to expand the current two step wizard for such a small thing.
Flag system
During the build/version system rewrite, I recognized how important a flag system is. Previously, I thought it would be easiest to tag bugs for example with stuff like “blocks version X”, but that would be quite a rigid system with a few, hardcoded flags. I wanted a system where every project, module or bug could be tagged with an unlimited number of flags. But this creates some problems:
- How to store the flags?
- How to allows different flags for different modules?
My first idea was to create a flag table per flag group, with each column being a flag. Obviously, this system won’t scale very well. The next idea would be to store one entry per flag per bug it concerns. A quick calculation shows this won’t work, at least not the obvious way. Let’s assume there are 5.000 bugs in the database, and we add 3 flags - makes 15.000 new database entries that would have to performed when you click the “Add flag” button. The solution is to make 3-state flags: True, False, Not set. When a bug is show, and a flag has not been found in the flag table, the status is unknown. This delays the creation of flag entries until really needed and will become the system I’m gonna implent once the bug reporting is working again. So much for now!