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.
Yes! I think we really should avoid creating our own web framework and we definitely should avoid coding it all from scratch by ourselves. (Which is why I was looking at the Perl ecosystem to see what it provides out of the box for us to build upon.)
As to the question what problems can be solved by extending Dancer2, I think my answer would be:
* To address the non-HTTP-ish nature of the endorsed REST plugin, we can write our own
* To address the fact that our login functionality doesn't currently fit Dancer2::Plugin::Auth::Extensible, we could (try to) work with the author(s) to extend it to support our use-case
* I guess the need for a DSL with respect to route definitions for REST resources will always remain highly limited (iow, with or without a framework doesn't make a big difference)
* To address the framework configuration issue for the different cookies for different routes/apps: I guess that goes too deep into the framework to address on our own. I've mentioned this to "racke" (Stefan Hornburg) in our IRC channel when I worked with it, but reading the changelogs, I don't see anything which might have changed the situation.
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?
That's a nice dimension you're adding here to our evaluation. I hadn't thought about it that way. My first thought is that this *does* allow a more gradual migration of the code base to a modern structure as it separates the dispatch itself from the need to rewrite templates to be made consistent with Dancer's way of passing parameter values to templates and rewriting the code to be "Dancer2 code" instead of "PSGI code".
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.