Skip to content
This repository has been archived by the owner on Dec 14, 2018. It is now read-only.

Properties marked with [FromHeader] attribute do not use default values when a header is not present #1722

Closed
pranavkm opened this issue Dec 15, 2014 · 5 comments
Assignees
Milestone

Comments

@pranavkm
Copy link
Contributor

Consider:

public class ModelBoundType
{
     [FromHeader("Test-Header")]
     public string TestHeader { get; set;} = "Default-Value";

     public string TestModelBoundValue { get; set; } = "Default Value";

TestModelBoundValue picks up the default value when a value for the property is not found. TestHeader stays null when the a header is absent.

@pranavkm pranavkm added the bug label Dec 15, 2014
@rynowak rynowak added this to the 6.0.0-rc1 milestone Dec 15, 2014
@rynowak rynowak self-assigned this Dec 15, 2014
@yishaigalatzer
Copy link
Contributor

How does this work for other model binders when the value does not exist?

@rynowak
Copy link
Member

rynowak commented Dec 16, 2014

How does this work for other model binders when the value does not exist?

Other model binders aren't greedy and don't return true to halt model binding. The model binding system sees null and success = true and so sets the property to null.

@yishaigalatzer
Copy link
Contributor

The suggestion is to fix this by changing the context to have another flag that indicates if a value was produced. This flag will be set to true by default if the value setter was invoked.

@yishaigalatzer
Copy link
Contributor

We also want to consider as part of this change moving default value setting to a single location (where now it is spread between MutableObjectModelBinder and ActionExecutor

rynowak added a commit that referenced this issue Jan 16, 2015
This change adds support for our three-valued logic to the default value
handling part of the MutableObjectModelBinder.

The issue is that we want to look up a default value when a 'greedy' model
binder returns true but doesn't find a value.

We also don't want to call the property setter unless there is:
1). A value from model binding OR
2). A default value
rynowak added a commit that referenced this issue Jan 16, 2015
This change adds support for our three-valued logic to the default value
handling part of the MutableObjectModelBinder.

The issue is that we want to look up a default value when a 'greedy' model
binder returns true but doesn't find a value.

We also don't want to call the property setter unless there is:
1). A value from model binding OR
2). A default value
rynowak added a commit that referenced this issue Jan 16, 2015
This change adds support for our three-valued logic to the default value
handling part of the MutableObjectModelBinder.

The issue is that we want to look up a default value when a 'greedy' model
binder returns true but doesn't find a value.

We also don't want to call the property setter unless there is:
1). A value from model binding OR
2). A default value
rynowak added a commit that referenced this issue Jan 16, 2015
This change adds support for our three-valued logic to the default value
handling part of the MutableObjectModelBinder.

The issue is that we want to look up a default value when a 'greedy' model
binder returns true but doesn't find a value.

We also don't want to call the property setter unless there is:
1). A value from model binding OR
2). A default value
rynowak added a commit that referenced this issue Jan 17, 2015
This change adds support for our three-valued logic to the default value
handling part of the MutableObjectModelBinder.

The issue is that we want to look up a default value when a 'greedy' model
binder returns true but doesn't find a value.

We also don't want to call the property setter unless there is:
1). A value from model binding OR
2). A default value
@rynowak
Copy link
Member

rynowak commented Jan 17, 2015

1e7812e7e0e5fc2e4e0d726f5903f9a8259c254

@rynowak rynowak closed this as completed Jan 17, 2015
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants