Select helpers unable to resolve slightly-complex expressions

[dougbu]

The expression-based select helpers (@Html.DropDownListFor() and @Html.ListBoxFor()) are able to handle only simple property-path expressions (e.g. model.Property1.Property2) when passed a non-null selectList argument. Any more complex expression generates a <select/> with no selected <option/>, despite a non-null expression result. This is confusing and limits the expression-based select helpers to what their string-based equivalents support.

This issue affects the <select/> tag helper as well. It always passes a non-null selectList argument to the underlying generator.

For example

  @Html.ListBoxFor(model => model, selectList)

works fine and will select the correct <option/> element in the generated HTML. But

  @{
    var collection = Model;
    @Html.ListBoxFor(model => collection, selectList)
  }

selects no <option/> elements in the generated HTML. Indexer expressions encounter the same issue.

Worse the expression is actually evaluated against the ViewDataDictionary content, potentially leading to incorrect expressions. None of the expression-based HTML helpers should use ViewDataDictionary at all. (Well almost none: The select helpers get their fallback selectList value from that dictionary.)

Workaround is to place the IEnumerable<SelectListItem> value in the ViewDataDictionary and pass selectList: null to the select helper. This uses the ViewDataDictionary entry and causes the helper to correctly evaluate the expression. But this workaround isn't discoverable and does not help the <select/> tag helper.

---

Root cause: The generator code falls back to ViewData.Eval() when determining the selected values. That method supports a very restricted set of expressions -- much less than can be done with a lambda.

[rynowak]

See SelectTagHelperTest.GeneratesExpectedDataSet (look for the TODO) when this is fixed for some test cases to enable.