playframework / playframework/twirl
Allow per-package template imports
Nobody has claimed this yet.
- Dominant language
- Scala
- Stars
- 561
- Forks
- 118
- Avg merge
- 1d 15h
- Merged PRs (30d)
- 29
Description
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 inbuild.sbt, but is a clean way. - Move imports out of
build.sbtfile (while retaining keytemplateImportsfor compatibility, but making it deprecated). For example, there can be file like_imports.scala.htmlthat 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.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the existing templateImports setting in build.sbt and compare it with the proposed _imports.scala.html approach. Review the three scoped-import designs and determine which API and compatibility behavior should be agreed on before implementation. Done means the project has a decided scope and an accepted implementation plan.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- scala
- Domain
- build-system, web-dev
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100