playframework / playframework/twirl

Allow per-package template imports

Open
#92 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

status:backlog
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:

  1. 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.
  2. 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.
  3. 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.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.