Currently, the cfg.py is very powerful as it controls all the input from the config file and the resulting class creations and meta/aoi data handling.
For a better separation and later on also testability, there should likely be another config class, e.g., a CFGModuleHandler() to actually creates/instantiates the specified modules in the config file (maybe to be called by the job handler or wherever its needed?).
It will always need the getters from the Configuration() class, but could also be used to streamline the process in the proc.py processors by also creating those classes based on the specified Sensor, instead of them being created by the Listing/RetrievalProcessor()'s themselves? Potentially through some methods like get_swath_handler() or get_listingprocess_handler()
Currently, the
cfg.py
is very powerful as it controls all the input from the config file and the resulting class creations and meta/aoi data handling.For a better separation and later on also testability, there should likely be another config class, e.g., a
CFGModuleHandler()
to actually creates/instantiates the specified modules in the config file (maybe to be called by the job handler or wherever its needed?).It will always need the getters from the
Configuration()
class, but could also be used to streamline the process in theproc.py
processors by also creating those classes based on the specified Sensor, instead of them being created by theListing/RetrievalProcessor()
's themselves? Potentially through some methods likeget_swath_handler()
orget_listingprocess_handler()