Refactor: split up feature model anomaly solver into different anomaly types

[schweikart]

No description provided.

[Elscrux]

The separate feature model solvers are much better now. Since we are using the Webflux framework now, the only real overhead of this approach is the additional meta solver, which is valid and perhaps even desired.

[schweikart]

the only real overhead of this approach is the additional meta solver, which is valid and perhaps even desired.

We might even be able to get rid of that. We could implement an abstract SingletonProblemSolver extends ProblemSolver implements MetaSolver that implements the MetaSolver methods automatically. This could be used for problems with only a single solver.

[Elscrux]

We might even be able to get rid of that. We could implement an abstract SingletonProblemSolver extends ProblemSolver implements MetaSolver that implements the MetaSolver methods automatically. This could be used for problems with only a single solver.

I'd rather keep it as it is, as a SingletonProblemSolver kind of goes against the point of a MetaSolver which should handle multiple solvers. We might not want to create another solver for something like a dead features anomaly in feature models, but at least we support it.

[schweikart]

I've fixed toolbox-web to use this new route scheme in ProvideQ/toolbox-web#25

[schweikart]

I've finally gotten to revising this PR now 😅

If this works for you now, please merge this PR into refactor/controllers first so the tests over there pass as well. Then we can merge #39 as well :)

[Elscrux]

We still need the url as part of the record. See here for its usage: https://github.com/ProvideQ/toolbox-web/blob/develop/src/components/solvers/SolverPicker.tsx#L123

What we should do here instead is only require the problem type and description in the constructor for SubRoutineDefinition so the url part can be inferred from the type.