You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Dec 14, 2018. It is now read-only.
@harshgMSFT please update this comment with the suggested design.
Including how we deal with [FromBody] appearing twice, is there a TryUpdateModel for the controller? What we do about validation?
Initial thoughts:
Representation :
Controller properties are treated as additional action parameters which are common for all actions.
This gives us a single place where we can bind all controller properties ( which are interesting, more on this later). along with actual action parameter. This will ensure things like validation and handling of multiple [FromBody] attributes is uniform and is at one place ( model binding phase).
Also since the information about the controller properties (of interest) will be part of Action descriptor it will also be available to api explorer.
Since action parameters are passed as a dictionary to any action filters we will have a custom dictionary with source as the controller object. This will ensure any modifications to the dictionary reflect on the controller instance.
This would also mean any conflicts in name would be disastrous as they will override each other's value. I would recommend this dictionary to be case sensitive ( which is the case currently) to avoid name clashes.
Discovery of Controller properties:
The discovery happens when action descriptor is created, viz. in ControllerActionDescriptorBuilder
There are four categories of public properties which can be defined on the controller
Those without any Model binding related attributes (eg From*, ModelBinder etc). and without any Activate attribute.
Those with only activate.
Those with only model binding related attribute.
Those with both activate and model binding attributes.
Case 1 and 3 should be considered as action parameters while case 2 and 4 should not.
Case 4 is weird and we should consider it as an invalid scenario and throw.
Also we should provide an opt out mechanism for controller properties which need to be excluded from model binding. We can consider this to be similar to [BindNever].
The text was updated successfully, but these errors were encountered:
The controller properties are not present in the actionArguments dictionary. If a filter needs it, he can get it via controller object.
Activate attribute will be no longer applicable for Controller ( will still be used for view components etc). The activate concept for controllers will be replaced by a new attribute like FromBinding (or ModelBinderAttribute.. the jury is still out on that.).
Controller properties are opt in.
Controller Properties will be added to actionDescriptor.Parameters collection.
Validation, ApiExplorer, Errors for multiple FromBody, work as they look at actionDecriptor for parameters.
@harshgMSFT please update this comment with the suggested design.
Including how we deal with [FromBody] appearing twice, is there a TryUpdateModel for the controller? What we do about validation?
Initial thoughts:
Representation :
Controller properties are treated as additional action parameters which are common for all actions.
This gives us a single place where we can bind all controller properties ( which are interesting, more on this later). along with actual action parameter. This will ensure things like validation and handling of multiple
[FromBody]
attributes is uniform and is at one place ( model binding phase).Also since the information about the controller properties (of interest) will be part of Action descriptor it will also be available to api explorer.
Since action parameters are passed as a dictionary to any action filters we will have a custom dictionary with source as the controller object. This will ensure any modifications to the dictionary reflect on the controller instance.
This would also mean any conflicts in name would be disastrous as they will override each other's value. I would recommend this dictionary to be case sensitive ( which is the case currently) to avoid name clashes.
Discovery of Controller properties:
The discovery happens when action descriptor is created, viz. in
ControllerActionDescriptorBuilder
There are four categories of public properties which can be defined on the controller
Case 1 and 3 should be considered as action parameters while case 2 and 4 should not.
Case 4 is weird and we should consider it as an invalid scenario and throw.
Also we should provide an opt out mechanism for controller properties which need to be excluded from model binding. We can consider this to be similar to
[BindNever]
.The text was updated successfully, but these errors were encountered: