Added value_template_string property to BaseInput

[monim67]

Fixes:

• Button translation issue Translation does not work for button used within common layout #960.

What has been changed:

• Added a new property value_template_string to BaseInput class.

How it fixes the issue:

The additional property value_template_string preserves the original value passed to sub-classes
of BaseInput from being overwritten in the render method.

[codecov-io]

Codecov Report

Merging #961 into master will not change coverage.
The diff coverage is 100%.

@@           Coverage Diff           @@
##           master     #961   +/-   ##
=======================================
  Coverage   95.62%   95.62%           
=======================================
  Files          24       24           
  Lines        2768     2768           
  Branches      244      244           
=======================================
  Hits         2647     2647           
  Misses         79       79           
  Partials       42       42

Impacted Files	Coverage Δ
crispy_forms/layout.py	96.23% <100%> (ø)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 1d355c9...f396c20. Read the comment docs.

[smithdc1]

Hi @monim67 - thanks for looking into this!

Do you think we should have a small regression test?

[monim67]

@smithdc1 how can we do that? So far the tests run successfully so and I have checked the input renders properly after this change. Do you have anything on mind?

[smithdc1]

I had a look at your heroku demo app which I think you've updated for the change as the buttons now change language.

In this version it doesn't look like it's working as intended. Whilst the labels change language ok, the button behaviour is a bit random.

[monim67]

The heroku app is intended to demonstrate the bug, it does not include the fix. And the button labels don't change language. You might be seeing a cached version there.

[carltongibson]

Traditionally we've said that if you need translation then you must instantiate your layout objects in a per-request context, such as a form's __init__. You can wrap the shared layout in a helper/factory function to keep it DRY.

Making the values properly translatable would be a reasonable addition I think. But it would be a new feature, and I think we should make sure we've thought it through fully before just sneaking it in. (Including tests, and documenting any new attributes.)

c.f. #776 here, which looked at the same issue. (Not sure if the approach was sound or not as yet.)

An alternate approach I was pondering whilst thinking about this, but haven't thought through, is finding a way of not needing to overwrite value each time through render... (From the second pass it's a noop — can we lazily evaluate it somehow? — Not sure as yet.)

[monim67]

@carltongibson while looking into it the lazy object also came to my mind, but if I assign a lazy object to value in the constructor then it will require the context object from render function to evaluate, so it's not going to work unless we find a way to pass the context.

The simple solution I thought was separating two value variables instead of overwriting, the one passed to the constructor value_template and the one passed to html template rendered_value. I was in a confusion about which one to rename. I chose to rename the value_template considering the affect was less.

We should really think deeper before we decide how to provide the feature. Haul me if I can be of any help 👍