One week since my last writing, and the code-scape is looking already very different. I decided today that this was one of those projects requiring at least one rewrite from half-scratch, so I’ve been refactoring in an effort to fight the spaghettitude that was already making things difficult. The new and even more object-oriented organization is:
- raw data is held in a container which
- (a) does all format-checking of received strings, and
- (b) can provide raw data requested by label
This is requiring some comparatively heavy code, but it is covered up by the clean and flexible interface methods get(label) and store(). The major benefit is that this way, string format can change and the code to access fields won’t — if one method needs geiger_ticks, it can always get geiger_ticks by calling container.get(“geiger_ticks”). This class is informed by another new thing…
- format is given by two text documents, one containing expected format of received data and the other containing the format in which to output data.
Short parsers turn these files into dictionaries holding the proper locations of incoming and outgoing data. These dictionaries live in the containers, speaking of which:
- converted data is held in a container which
- (a) formats the data it is given piece by piece, and
- (b) saves the data in the appropriate files when told to
Data is given to this container by…
- datafield objects have been updated to map to output fields rather than input fields, which is more robust and flexible.
- each datafield object will inherit from some DataField class that knows how to check range, keep track of error state, and so on
This is much like the previous system except it does not assume that each input takes only one output.
It is my hope that separating data handling from scheduling will make for better code and easier maintenance by Tom and Doug, who (this way) will only need to change a configuration file to alter formatting. Another part of the refactoring is that error notifications are now separated from the weather collector object. They live in errors.py and can be used easily by all pieces of the code.
As for something completely different: I have begun working on Tom’s control panel (using python and Tkinter). Simplifications necessary for that (ie a common formatting conf doc) prompted the changes to the main program I’m working on now. Time permitting, these should let me do some useful things — like automatically display new datafields in the control panel when they are added to the board’s conf docs.
- To Do (the list has grown):
- finish writing InDataContainer (est. 2 hours)
- write OutDataContainer (4 hours)
- rework DataField class definition (1 hour)
- move error things into errors.py (.5 hour)
- retouch WeatherCollecter class definition to fit with these changes (1 hour)
- start defining what datafields I have (1 hour)
- finish control panel (7 hours?)
- generate display from conf doc (3 hours)
- send commands to board (2 hours)
- get data from board(2 hours)
–Soren