Unable to utilize ModelExpression with [HtmlAttributeName(DictionaryAttributePrefix = "myprefix-")] Dictionary

[cjrosa]

Within razor, I've created the following:

<div myprefix-test="@Model.Value"></div>

I'd like to be able to create a tag helper with the following so I can create multiple [expression bound] attributes witht he same prefix.

     [HtmlAttributeName(DictionaryAttributePrefix = "myprefix-")]
        public IDictionary<string, ModelExpression> Values { get; set; } = new Dictionary<string, ModelExpression>();

However when running the application, I receive the following as runtime:

Dictionary values must not be of type 'Microsoft.AspNetCore.Mvc.ViewFeatures.ModelExpression'.

I should note that the razor tooling accepts the markup above.

Any thoughts would be greatly appreciated.

[danroth27]

@NTaylorMullen @DamianEdwards Is there any specific reason to not support this?

[dougbu]

MVC supports ModelExpression only when used as the type of a tag helper property.

Further this is a rather large feature request with an unclear upside. With no enforced commonality between the dictionary values (beyond being lambda expressions), about all the tag helper could do is evaluate the expressions and convert them to strings. What would you like to do with those values?

I should note that the razor tooling accepts the markup above.

How is that relevant?

[cjrosa]

Thanks for the quick responses @danroth27 & @dougbu...

The use case centers around [strongly-typed] template generation for Angular 2. For example:

<input ng-bind-ngModel="MyProperty" ... />

becomes...

<input [ngModel]="myProperty" ... />

Utilizing DictionaryAttributePrefix would enable a simple set of TagHelpers that correspond to Angular's binding syntax:

https://angular.io/docs/ts/latest/guide/template-syntax.html#!#binding-syntax

Being "generic" (e.g. ng-bind-XXX) would allow for any Component property being able to be bound in this way. This becomes especially important when targeting @input annotations on UI Components. For example:

<my-button ng-bind-title="someTitleProperty" ... />

becomes...

<my-button [title]="someTitleProperty" ... />

While I certainly appreciate the effort to support ModelExpression the commonality [or lack of it] should be of no consequence to the TagHelper framework. The Dictionary's value being a primitive type, a user-defined class/interface, object, etc provides no more "clarity" then ModelExpression as it's up to the author of the TagHelper to interpret these values accordingly, regardless.

As far as my note regarding the razor tooling, I was simply pointing out that this issue was not surfaced until run time. Ideally, such "things" are flagged at design time.

[dougbu]

ModelExpression is not just a primitive type. Something needs to create the ModelExpressions and the lambda expression needs to be based on the Model type.

I'm still not understanding the value of generating property.Add("title", new ModelExpression(m => m.someTitleProperty)) versus property.Add("title", someTitleProperty) i.e. using a Dictionary<string, string> property and ng-bind-title="@someTitleProperty".

[cjrosa]

ModelExpression is not just a primitive type. Something needs to create the ModelExpressions and the lambda expression needs to be based on the Model type.

My apologies, I was not asserting that ModelExpression is a primitive type. Instead I was indicating that the Dictionary's Value type should be honored, regardless of type (e.g. primitive, class/interface, object, and ideally ModelExpression). I do understand, ModelExpression is special!!!

I'm still not understanding the value of generating property.Add("title", new ModelExpression(m => m.someTitleProperty)) versus property.Add("title", someTitleProperty) i.e. using a Dictionary<string, string> property and ng-bind-title="@someTitleProperty".

I need to get at the metadata for the Model's property. At a minimum, I need the property's name, but perhaps other metadata as I look to support more advanced templating scenarios. If I'm not mistaken, "@someTitleProperty" would simply yield that property's value, not its name (just tested and confirmed). Not to mention, that if the property was not a string (e.g. int),Razor seems to doing an implicit convert of int => string. In this case, someInt = 123 would generate [title]="123", this is obviously not the desired result.

[dougbu]

Do you need both the property's name and it's value? I'd like to understand whether you need a ModelExpression versus an editing context which helps you type only model property names i.e. use a Dictionary<string, string> property and ng-bind-title="someTitleProperty" but prevent typing ng-bind-title="notAProperty" .

[cjrosa]

I do not need the value... In fact, in all likelihood, I won't even have a controller given that the Component I've been referencing is being utilized in lieu of an actual controller. So, no return View(new SomeModel()) necessary.

So I understand, in the ng-bind-title="someTitleProperty" markup, how are the following distinctions to be made/enforced?:

• ng-bind-title="someTitleProperty" // The model someTitleProperty property's "Editing Context"
• ng-bind-title="someTitleProperty" // The string literal "someTitleProperty"

[dougbu]

how are the following distinctions to be made/enforced?

Your requirements are now much more clear. They might be satisfied any number of ways e.g. a new [HtmlAttributeName(OnlyModelProperties = true)] property and some tooling support. But your original Dictionary<string, ModelExpression> idea is likely less work. Put another way, I agree this is a valid use case for such a tag helper property -- the first we've heard about.

This issue is currently in the backlog, meaning we would accept a well-written PR filling the gap.

In the meantime, I'd recommend using a Dictionary<string, string> and having your customers use nameof in the .cshtml file e.g. ng-bind-title="nameof(Model.someTitleProperty)".

Your tag helper could also confirm the dictionary values match one of ViewContext.ViewData.ModelMetadata.Properties.Select(p => p.PropertyName). Hmm, that might be the cheapest solution here though it wouldn't be enforced at design time.

[cjrosa]

@dougbu, Thanks for the great exchange! The issue with @nameof is that you loose support for dot-notation:

@nameof(Model.MyClass.MyProperty) produces [title]="myProperty" when it should render [title]="myClass.myProperty", but...

Please pardon my ignorance, first time getting to this point. As for a PR, should I create one? is there a template? How to submit?

Thanks again!

[dougbu]

I agree deeper properties get more complex when using the tag helper enforcement approach. Probasbly best to have users type in arbitrary dotted property names and recursively checking each segment (at runtime) in the tag helper.

Note Dictionary<string, ModelExpression> has something of the opposite problem: There's no restrictions on the lambda expression used: While asp-for="myClass.myProperty" is common, asp-for="@randomVariable[23].someOtherProperty" is completely supported.

Feel free to create a PR. I suspect the core change will be in MvcTagHelperAttributeValueCodeRenderer but the bulk of the effort will be on tests. Fork the MVC repo in your own GitHub repo, create a branch containing the feature, then submit a PR in this repo using that branch.