I have a multiple view sets (for example, one view set for website, and one view set for admin panel of it), and they need some common imports (custom template magic) and some imports specific to the set. Currently Twirl has no way to specify a scoped import, so there is a suggestion to introduce one.
Currently I have three ideas on how to implement it:
Add some format to import string, like some.helpers._ @ some.views._, so first part is import itself, and second part is a scope of that import. It will not break any existing imports, but it's a dirty way, I think.
Create structure like case class TemplateImport(import: String, scope: String) and specify it either explicitly, or like SBT dependencies, provide an implicit conversion from string like "helpers._" % "views._". It possibly can break existing imports, because there is a chance that this implicit conversion will be out of scope in build.sbt, but is a clean way.
Move imports out of build.sbt file (while retaining key templateImports for compatibility, but making it deprecated). For example, there can be file like _imports.scala.html that will hold imports in a Twirl usual format for that package and all descedants. Will not break anything if we keep old key, but it's the most hard way.
I can implement this feature itself, but I think that it should be discussed before I implement it.
Another issue that isn't directly related to Twirl, but will help to test modified version with scoped imports - how to import modified version of Twirl into Play 2.4.6 project instead of built-in one?
I have a multiple view sets (for example, one view set for website, and one view set for admin panel of it), and they need some common imports (custom template magic) and some imports specific to the set. Currently Twirl has no way to specify a scoped import, so there is a suggestion to introduce one.
Currently I have three ideas on how to implement it:
some.helpers._ @ some.views._
, so first part is import itself, and second part is a scope of that import. It will not break any existing imports, but it's a dirty way, I think.case class TemplateImport(import: String, scope: String)
and specify it either explicitly, or like SBT dependencies, provide an implicit conversion from string like"helpers._" % "views._"
. It possibly can break existing imports, because there is a chance that this implicit conversion will be out of scope inbuild.sbt
, but is a clean way.build.sbt
file (while retaining keytemplateImports
for compatibility, but making it deprecated). For example, there can be file like_imports.scala.html
that will hold imports in a Twirl usual format for that package and all descedants. Will not break anything if we keep old key, but it's the most hard way.I can implement this feature itself, but I think that it should be discussed before I implement it.