jonathan: thuban/test test_baserenderer.py, 1.10, 1.11 test_layer.py, 1.34, 1.35
bh at intevation.de
Fri Feb 18 11:50:04 CET 2005
Jonathan Coles <jonathan at jpcoles.com> writes:
> if i add extra options to ProjectRasterFile then those options will have
> to be set somewhere. no matter where they are set it will require
> querying wxPython for its version.
> baserenderer will have to get those
> values before it calls ProjectRasterFile and then the tests that use
> baserenderer will fail because the call chain will use wxPython.
There are at least two solutions:
- BaseRenderer's draw_raster_layer method calls ProjectRasterFile
through a new method that can be overwritten by a derived class
- Add two new methods that return suitable values for the new
parameters. These methods can be overwritten by derived classes.
In any case the values for those flags have to be supplied by derived
classes such as MapRenderer. MapRenderer does depend on wxPython so it
can determine the values needed for the current version of wxPython.
>> That's why there's the MockDC and the SimpleRenderer in
>> test_baserenderer.py. The do not depend on wxPython at all and only
>> provide the interface the baserenderer needs.
> they don't depend on the wxPython libraries themselves, but you've
> assumed that we are using wxPython because of the names of the calls
> that are tested.
The tests assume they have a sufficiently similar interface. That
doesn't mean they have to have anything to do with wxPython. If
necessary you could adapt other rendering interfaces to the interface
expected by the Thuban renderers. A DC is not a very good interface for
that (it expects integer coordinates for example) but it was what was
already implemented. Of course, one could always implement a
completely new renderer that doesn't have anything in common with
Thuban's current renderers.
Intevation GmbH http://intevation.de/
More information about the Thuban-devel