ConfigParser
only stores config data
#53
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR simplifies the responsibilities of the
ConfigParser
object used internally:Communications_tech_list
is not given in config, it is now part oftechnology_switch
codecontainer_tech_list
which bundles togethermaven
,gradle
anddocker-compose
used to detect microservices, allowing it to be extended in the future with more technologiestemp.tmp.tmp_config
is nowcore.config.code2dfd_config
commit
field is now part ofRepository
group, notAnalysis settings
; the latter IMO should be left for code2DFD-internal thingsDFD
is not stored as a string inConfigParser
, it is now adict
ofmicroservices
,information_flows
andexternal_components
as an intermediate step before migrating to proper objectsdfd
object and get the necessary parts internally when necessary, in the end they set the updated datastructurestechnology_switch
is not used as a getter for services/information_flows, the functions are renamed toset_microservices
andset_information_flows
and are only called once, in the appropriate place inDFD_extraction
, all other functions get the data from thedfd
dictionary directly