Thanks Erik for taking the time to do this analysis. I've found Dancer2 to be one of the least opinionated and more flexible frameworks (compared with Mojolicious or Catalyst for example), so it's interesting to hear the difficulties you're running into. If, as your work seems to suggest, lsmb does not easily fit with Dancer2, I say we shouldn't force it. Using an established framework makes it easier for others to interact with our code base, through using common design patterns, but if we have to hack the framework or use it in non-standard ways, that advantage is lost. I wonder if we can extend Dancer2 to cover our needs, but your analysis suggests that would be quite invasive. I think we need to avoid, if possible, creating our own web framework from scratch, but we can perhaps enhance what we have. To pick out and respond to a few of your comments:
So, it seems that managing instantiation of the templating library is more important than abstracting it.
Agreed. I see no big advantage in abstracting the templating library.
With the ability to define routes, we'll be able to detach URL structure from our internal code structure.
This for me is one of the key improvements we can make to our code base - easier to maintain, test, understand, re-use. But we can achieve that - and perhaps achieve a more gradual evolution of our code base by way of...
Route definition and dispatch (including extraction of route parameters) is available in a technology agnostic library Router::XS
This looks pretty decent to me. Do you have any thoughts as to how easily we could adopt Router::XS? Does that start to provide a more gentle path to restructuring? We've discussed before the decision to evolve the code base, rather than starting afresh. I think that's right, so the idea of gradual improvements appeals to me. Best wishes, Nick