Most string-based HTML helpers use unprefixed ViewDataDictionary entries if called from templates

[dougbu]

The string-based helpers not mentioned in #1485 (@Html.TextArea() etc.) also do not behave as expected in template views. But this problem occurs only if an entry exists in the ViewDataDictionary matching the (un-prefixed) expression name. So unexpected values will be used in the generated HTML -- luckily, in a somewhat narrow case.

E.g. action contains

ViewData["Age"] = 39;
return View(new User()
{
  Age = 26,
  Dependent = new User()
  {
    Age = 13,
  },
});

Index.cshtml contains

@Html.DisplayFor(model => model.Dependent, templateName: "Dependent")

DisplayTemplates/Dependent.cshtml contains:

<td>
    @Html.Label(expression: "Age", labelText: null, htmlAttributes: new { @class = "control-label", })
</td>
<td>
    '@Html.Value(name: "Age")'
</td>

Result is:

Expect to see "13" displayed between the quotes.

[dougbu]

This problem was inherited from MVC 5.2.

Fix would probably require a general change in how we evaluate expressions that may be in ViewDataDictionary or its Model when !string.IsNullOrEmpty(ViewData.TemplateInfo.HtmlFieldPrefix). In that case, the full name of a dictionary entry and its name relative to the current Model are different. Should pass both names to ViewDataEvaluator.Eval(), allowing that helper to evaluate the full name against ViewDataDictionary entries. Then, if that fails, the helper would evaluate the relative name against ViewDataDictionary.Model. This preserves the current precedence of ViewDataDictionary entries over properties of ViewDataDictionary.Model.

The current code mixes ViewDataDictionary lookups with evaluating properties in the Model. This works fine in many cases, but not in this specific situation.

Fix isn't particularly risky because we have good but still-improving (see @pranavkm's work on #453) unit tests touching on ViewDataEvaluator.Eval(), Also have functional tests and samples demonstrating the behaviour of various HTML helpers.

[dougbu]

Problem also affects how client validation attributes are found. For example with the following in an Int32.cshtml template,

@{
  // Don't do this; causes template to ignore `ViewData.Model` and overwrite existing `ViewData`.
  ViewData[string.Empty] = "two";
  ViewData[Html.ViewData.TemplateInfo.HtmlFieldPrefix] = 23;
}

@Html.TextBox(expression: string.Empty);

The generated HTML will be

<input id="z0__Number" name="[0].Number" type="text" value="23" />

The HTML helper finds the correct value but the incorrect ModelMetadata. (Client-side validation should require the int value but no data-val-required attribute is generated.)

[dougbu]

27283ec