Allow BindPropertyAttribute to be specified on PageModel \ handler

[jchadwick]

The default model binding convention of PageModel classes should be that all properties are automatically candidates for model binding. Just like you do not have to specify the [Bind] attribute on controller action arguments in order for them to be model binding candidates, you shouldn't have to put [BindProperty] on the PageModel properties, either. Not only is opting in the opposite of the default MVC model binding behavior, it is implemented not through the BindAttribute but through an entirely different attribute, which means that developers need to learn two different approaches for the same basic functionality.

In addition to the cognitive overhead, it also has a negative impact on usability when combined with forms using XXXFor HTML helpers and Tag Helpers since these helpers operate off of the model defined by @model and @model would typically point to a PageModel code-behind. It's overbearing to have to put the [BindProperty] attribute on every single property, so I'm going to prefer creating another class to use as a single property and place [BindProperty] on that. This has the net effect of "namespacing" each of the form fields (what was name="FirstName" is now name="Customer.FirstName". Other than this "namespacing" being inefficient and introducing other subtle naming side-effects (e.g. browser form field autocomplete for standard fields like "password" no longer match), from a design/architecture standpoint this new class effectively becomes a view model within what's already supposed to be a view model, which gets awkward.

[Eilon]

@rynowak @DamianEdwards - thoughts?

[rynowak]

This is intentionally the same as controllers. Moreover using properties that don't have a binding attribute makes them view-model-like.

If you want to change this, it's easy to do with a convention.

[kdowswell]

I expected Razor Page - PageModel properties to act as @jchadwick indicated as well. Having to worry about a second class or adding the BindProperty attribute to all properties seems wrong.

[jchadwick]

@rynowak But that's the thing - it's not like controllers. The BindPropertyAttribute is not available on controller properties, and even if it were, that'd just be weird - when dealing with controller actions, why wouldn't you just use parameter binding?

I don't understand the claim that "using properties that don't have a binding attribute makes them view-model-like". Why does the view (or the view model) care whether the property was populated by the developer or via model binding?

Also, even if it is technically possible to change this behavior with a convention, I'm very specifically talking about the default behavior.

[Eilon]

@jchadwick - If we made the [BindProperty] attribute apply to classes (including base classes), and it would thus apply to all of that class's properties (including derived/base properties), would that alleviate this for you?

We can't change the default because it would be a significant breaking change.

[DamianEdwards]

I believe the attribute supported being placed on the entire class in the original prototype so that all properties would get model bound. I think we should support that.

[rynowak]

Yep, we ended up cutting it for RTM because really getting it right with inheritance requires some doing. We could do it if it solves a real need, which is why I'm suggesting it now.

I don't understand the claim that "using properties that don't have a binding attribute makes them view-model-like". Why does the view (or the view model) care whether the property was populated by the developer or via model binding?

This is an important distinction for security. If you are computing a property on the server side like Message = "Hello Billy, please dial (555)-867-5309 to speak with customer service" we want to make sure that this property can't be set via any user input. If that could could be computed OR populated by model binding, then a malicious site could redirect customers to your site, but send you to a different customer service line 😆

This can be a problem any time you're dealing with user input - but the point is that you the developer need to care not that the view cares. We wanted to you to make a choice for properties that accept user input and properties that don't. We're very cautious about making user input on by default, hence the choice that property binding is opt-in.

By the way controllers do support property binding, and it's also opt-in. The common usage we see for this is for headers in APIs where the API expects a given header to be submitted for all actions.