Here we go, with the first update round for today.
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.
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.
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.
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.
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!