Why? Because it is complex and opaque making dev harder, especially for developers who are new to this plugin?
idea from Dscho - run through the de-Torvalds filter:
The DataContainer is cute, if perhaps rather over-engineered.
The makes it hard to sit a new developer (or Dan White) in front of the Coloc2 source code and figure out how its working.
Example: its hard to figure out where the color map is set.
Example: Due to the many indirections in the container, it is pretty tricky debug into it.
(Dan wonders what "indirection" is, and has to check on Wikipedia...)
A solution might be to:
First, make everything explicit (again).
Remove the DataContainer and replace it with direct data flows that are easier to follow and understand, building on the nice ResultHandler idea.
The SingleWindowDisplayand pdf outputter implementations of ResultsHandler are two completely separate things... and should do their own thing, but use the same data.
Why? Because it is complex and opaque making dev harder, especially for developers who are new to this plugin?
idea from Dscho - run through the de-Torvalds filter:
The DataContainer is cute, if perhaps rather over-engineered. The makes it hard to sit a new developer (or Dan White) in front of the Coloc2 source code and figure out how its working. Example: its hard to figure out where the color map is set. Example: Due to the many indirections in the container, it is pretty tricky debug into it. (Dan wonders what "indirection" is, and has to check on Wikipedia...)
A solution might be to: First, make everything explicit (again). Remove the DataContainer and replace it with direct data flows that are easier to follow and understand, building on the nice ResultHandler idea. The SingleWindowDisplayand pdf outputter implementations of ResultsHandler are two completely separate things... and should do their own thing, but use the same data.