Progress Report

I've been working steadily on the Agenda Rewrite, probably about 15 hours per week.  I'm happy to report that progress is good. 

I've got the basic operations running for adding items and displaying views.   I'm learning  Jquery (http://jquery.com) – what a fabulous tool – as the basis for my user interface.

The strategy of testing before coding has fallen away.  One of the reasons is that I have refactored and refactored – redesigning as I understand each of the design problems better.   I'm in awe of the original designers, and humbled by how hard this program is to understand - even with a working model in front of me.

Instead of test-driven programming, I'm back to my favorite strategy of data-driven programming.  For example, I have a central repository of 'fields' in a CSV file.  Agenda has hundreds of fields that control the behavior of Views, Items, etc.   It controls how the data gets written to databases, what the initial values are, and how HTML forms are presented, validated, and unloaded.  

I've moved as much 'code' to this table as possible.  The code that exercises this data gets thoroughly tested – there is only ONE way to draw a form, even though there are a dozen forms in the system  - and an error in a data table is often easy to find mechanically.



By now, the database objects have been fully refactored three times.  The first cut was to create one for every type of entity – files, views, sections, columns, items, categories, etc.   

I have programmed carefully – there was a database class, and a datatable class that inherited from it.  There is an interface that described the minimal set of operations that these classes would provide.  Each of my entities had a further class which would hold any special SQL statements that I wanted – there was no SQL allowed outside this set of classes.

Although I didn't use an Object Database, my data design centered around a 'cargo' field for every entity containing a serialized array and an object to interpret it.   I get most of the benefits of an OODB, but still use MySQL  

This cargo was the only thing I sent to the datatable classes, they were responsible for reaching in and finding the appropriate key fields that were needed for SQL performance.

I quickly realized that 'file' is different from the rest, if for no more obvious reason than because the rest all had 'fileID' as a key and it didn't.  It struck me that maybe I should have an internal file system for tracking information about files (such as permissions, versions, etc), and maybe that was just a 'system' Agenda file with a special name.

But this fell by the wayside quickly because of the bootstrap problem.  I needed a file system to get some programming done, and I needed a lot of Agenda to be working in order to have a file system.

By this time, I had reconsidered where I wanted to store the database objects.  The 'View' table will be very infrequently updated compared to the 'Item' table, and the 'Assignment' table (linking items to categories) didn't fit into this model well. 

I found my early code would read the file record, and then quickly grab view, section, and column records - they were all required.   It seemed more efficient to park them with the file record even if it got a lot bigger.

So I refactored again – turning the 'File' cargo into a repository for File, View, Section and Column.  When I loaded a file, I got the complete schema for every way that you could present the view.

Now I have a new class layer - ' Instance' – with an interface a set of operations against these entities.  Instance works the same way regardless of whether I'm asking for a View (which is physically in the File table) or an Item (which has its own physical table).

I'm ambivalent about whether to put Categories into this big file object.  There's lots of information in them that is needed to present a view, and many operations need every possible category to be checked.  I've hedged by coding their Instance to put them into the File table, just need to be careful never to short-cut directly to them.



The joy of programming without a schedule is that I can continue to refactor until I get it right.  With each step I take, I learn more about the underlying problems that the original designers had faced.

I have made a few small changes in their design, nothing important.

For example, I never liked 'Sections' in the original Agenda.  If the sections described a set of similar children in the category tree, the view always had to be tinkered with if you added another child (for example adding a new salesman to a view that had a section for each salesman).   But sections could also be completely different from each other.

The need for sections is to allow related stuff to be bundled into a single view.   So that's the way I'm treating it.  Each View will have a set of tabs ('Tabviews') that can be completely different.   Each tab will have either a single section based on a category, or a group of identical sections based on the parent of a set of categories (with an accordion control to view them).

I think this represents what the original programmers were trying to achieve.




I'm starting to think about finding a name for this project.  'Agenda Rewrite' doesn't seem elegant.

If anyone has a name suggestion, I would be happy to hear about it.




Nothing planned for the next three weeks.   My lovely bride is taking me for a bicycle vacation in Italy - I shall be climbing the hills of Emilia-Romagna from  a base at the Belvedere Hotel in Riccione.

http://www.belvederericcione.com/en/about-belvedere-bike/