Replacing DropDown TV IDs with Human-Friendly Labels in Templates

A common Evolution pattern is to store a short internal value in a DropDown TV and then decide on richer frontend output later. The legacy example used a TV called agents and wanted that stored value to control which chunk was rendered.

The Basic Idea

Instead of printing the TV value directly, use the stored value as a switch and output a corresponding chunk, label, or block.

[+phx:if=`[+agents+]`:is=`1`:then=`{{agent1}}`:else=``+]
[+phx:if=`[+agents+]`:is=`2`:then=`{{agent2}}`:else=``+]
[+phx:if=`[+agents+]`:is=`3`:then=`{{agent3}}`:else=``+]
[+phx:if=`[+agents+]`:is=`4`:then=`{{agent4}}`:else=``+]
[+phx:if=`[+agents+]`:is=`5`:then=`{{agent5}}`:else=``+]

When This Is Good Enough

This pattern works well when the list is short and stable. Editors pick one controlled option, and the template decides what that option means on the frontend.

When to Refactor

If the dropdown begins controlling too many output branches, it may be time to move from a simple TV to a more explicit data structure or a dedicated snippet that maps values in one place. That keeps the template from turning into a long wall of conditional checks.

The underlying lesson is still valid: stored values are not always presentation values. It is often cleaner to map them deliberately before rendering the final page.