I've learned how to create a custom ModelBinder that successfully changes the way the properties are set as parameters of my controller actions.
Now how do I intervene the inverse way? changing the way it sets the property back from the model to the View in the EditorFor method?
You can use Default Templates.
This is basically a snippet of code that is used for the type. It needs to be in the Views\Shared\DisplayTemplates and Views\Shared\EditorTemplates.
Name of the view needs to be name of the Class.
This way you may change DateTime and other basic types as well.
I'm using ASP.NET MVC3 and i'm wondering that the default modelbinder binds to public properties but not to public fields.
Normally i just define the model classes with properties but sometimes i use some predefined classes which contains some fields. And everytime i have to debug and remember that the modelbinder just don't like fields.
The question: Whats the reason behind it?
but sometimes i use some predefined classes which contains some fields
While I cannot answer your question about the exact reason why the default model binder works only with properties (my guess is that it respects better encapsulation this way and avoids modifying internal state of the object which is what fields represent) I can say that what you call predefined classes should normally be view models. You should always use view models to and from your controller actions. Those view models are classes that are specifically defined to meet the requirements of the given view.
So back to the main point: fields are supposed to be modified only from within the given class. They should not be accessed directly from the outside. They represent and hold internal state of the class. Properties on the other hand is what should be exposed to the outside world. Imagine that in the property getter/setter you had some custom logic. By modifying directly the field this custom logic would be broken and potentially bring the object into an inconsistent state.
Maybe the reason for ignoring fields is to increase performance of the binder. Instead of searching all the Fields and properties. The Model Binder search for Properties only.
Though I think the Model Binder use cache to improve performance.
DefaultModelBinder exposes a public method:
DefaultModelBinder.BindModel, and a number of protected method available for overriding. All of them listed here.
Besides the model, these method refer to properties only, not fields, like
GetModelProperties,
GetFilteredModelProperties,
GetPropertyValue,
OnXYZValidating,
OnXYZValidated,
OnXYZUpdating,
OnXYZUpdated,
GetXYZValue,
where XYZ stands for either Model, or Property/ies, or both, and so on.
As you can see there is no Fields mentioned with these names whatsoever. As Darin explained no direct changes to Model's state are tolerated by the Binder. Hence no Field in its methods.
And also, you may wish to take a look at another important class: ModelBindingContext. An instance of this class gets passed to the BindModel, and subsequently to BindSimpleModel, and BindComplexModel, depending on model type (string, int,... are considered simple, everything else is complex).
So, this context has the following properties:
ModelXYZ, and
PropertyXYZ.
In other words you have no means to reference the fields in your ViewModel unless you do not override these classes and undertake special actions to do so.
But again, beware of fighting the framework, its always easier to follow it instead.
EDIT: The ModelMetadata class holds all the data needed to bind the model. Its code however, shows no sign of fields, field names, etc. Only properties are referenced and accessed. So, even if you try to inherit and override DefaultModelBinder and ModelBinderContext, you still won't be able to access fiellds, nevermind what their access modifier is: public, private, etc.
Hope this explains most of it.
I'm currently trying to programmatically insert a ModelClientValidationStringLengthRule ModelValidator via a custom attribute, and wishing to avoid adding to the AdditionalValues dictionary in order to make use of existing functionality.
This is due to using a CMS, and wanting to control the length of the string via the CMS rather than within a model.
I assume I would do this in the OnMetadataCreated event in the custom attribute, however I cannot see how to add to the ModelValidator collection, only get them via GetValidators...
Anyone have any ideas?
Thanks in advance,
Dave
Rather than adding a custom attribute, you want to inject a validator based upon a condition.
You can use the class I detail in this answer to inject your validator based upon the conditions in your CMS.
I have lots of MVC validation attributes on my model. Everything works great when the defaultModelBinder binds my model on submit. But, I need to create a custom modelbinder. I'd like to continue using my validation attributes. Can I? If so, how?
I'm not sure whether this is possible or not, but one thing I can say is that if it is possible then the extension points for default model binder don't make it very discoverable. I spent several hours one day trying to get this to work to no avail.
In lieu of getting this to work, you can use the Controller's TryValidateModel() methods.
I have created a create view within my MVC 2.0 Application and by default it included a field for the integer ID Column.
This is definitely a field i do not need.
If i remove the field and use updatemodel when trying to create the object in code, will something break because it doesnt see my ID column data being passed in, even though it is auto increment?
Also, i noticed that in the NerdDinner example, updatemodel was used and after that the repository.save method was called.
I thought that updatemodel would save the object to the database..why then call the .save method afterwards? Or have i missed something?
Any help with this would be appreciated.
Cheers
As I understand it, the UpdateModel method will blow away all data in the object. This is because MVC is round-trip based. Anything that goes out should come back if you need to keep state. See this question for more details.
A better way to handle this scenario in my opinion is to have an input model class as an Action parameter which is passed to a service call to update the domain entity in the DB. (Or this mapping code could be right in the action method if you really want.)
Also please be aware of the security vulnerabilities that could be introduced by binding directly to your DB model.