Maybe it's just that it's been a while, and time always produces bugs, but I kind of want to re-architect DMU's entire conversion system.
Right now, analyzers and converters are two distinct plugin types that have nothing to do with each other. Analyzers only determine if there is a problem, then converters are entirely responsible for taking the necessary steps to correct the issue (if possible). I'm now thinking this is kind of inefficient and weird.
What I'd like to do is make analyzers responsible not just for determining if there is a problem (and generating the documentation, of course), but also the nature of the fix. I'd like to see analyzers generate machine-readable "steps" to fix a particular issue. By doing that, monolithic converters can be ditched entirely in favor of highly testable micro-routines.
Let's take a call to variable_get as an example: variable_get('foo_is_available', true)
An analyzer should look at this and determine that the following steps are necessary:
- A foo.settings config file needs to be created
true
needs to be set for foo.settings.is_available- variable_get is renamed to \Drupal::config('foo.settings')->get('is_available')
It could then generate a bunch of steps, in a YAML file, that look something like this:
create_file: ~/config/install/foo.settings.yml set_default_config: file: ~/config/install/foo.settings.yml variable: is_available value: true function_to_method_call: function: variable_get class: \Drupal method: config arguments: - foo.settings chain: - method: get arguments: - is_available conditions: argument_is: index: 0 value: foo_is_available
In this architecture, create_file, set_default_config
, and function_to_method_call
are plugins that perform some operation on the module code. They don't need to know the larger context at work.
Any thoughts on this? I think it'd be a more elegant way for DMU to work internally, as things can easily get out-of-hand when a converter has too much to do.
Comments
Comment #1
phenaproximaComment #2
phenaproxima