Ok, so after migrating from MVC3 to MVC4 I ran into interesting problem.
We had a controller method with following signature:
public ActionResult Delete(Guid[] items)
This worked great in MVC3 but stopped working after upgrade to MVC4 - the items array is always empty. I realized that in MVC4 I would have to use ICollection instead to make it work:
public ActionResult Delete(ICollection<Guid> items)
Is that a breaking change? Or the first approach is not really a proper way of doing things that just worked as a fluke in MVC3?
The data that is posted looks very simple and looks like this:
items=52b37b94-1f53-4981-a698-9eb6eca30861&items=d2f8c5e5-4e04-4a97-8efd-643a4e87e48b
And is posted using jQuery ($.post)
Ok, I figured out what was happening. I started brand new MVC4 project to create a vanilla test case, and binding worked properly for both array and collection of Guids.
After digging I realized that during upgrade we also upgraded autofac DI container from version 2.5 to 3.0. Some internals may have changed and action injection got enabled by default.
Apparently action injection was interfering with model binding.
Related
Hi friends in webapi using mvc format i created one webapi project here i added autofac resolver to resolve DI(dependency injection) its working fine then in next step i took this dlls and created new project for this i added the dlls now in this project i added one controller but it is showing the error 'x(controller name)' Type controller does not have a default constructor but for this many people given solution for this add new bootstrap class(which contain autofac for di resolve) but i am inherting my old global.asax file from my current global.asax file so i think dont want to add again all the stuff the autofac resolver will get from old dlls so i find many solutions but now luck can any one help me
Note : please ask me incase of any clarity (my english is not good excluse me for this)
The Mistake I did is Spelling mistake this is if Controller name is SampleController i am putting SampleContoller (missing r in Controller splleing) thats it now i corrected splleing now its working fine
I have a class library which includes a custom MVC model binder to instantiate various concrete types which derive from an abstract class. The model binder is almost identical to the one described in this post.
It works fine when using it from within the same Visual Studio Solution that also includes an MVC web application for testing.
My problem is that having created a nuget package from the assembly and included it in a totally separate MVC application the model binder no longer works, despite having configured it correctly in Global.asax.cs.
After some hair pulling I recreated the model binder directly in the separate MVC app, and as I was doing so I noticed that the overridden CreateModel() method in the binder is protected. It now gets executed and I suspect the protected keyword has something to do with it but I would like someone to explain why exactly.
Even with the 'local' modelbinder there are more problems. When it executes, and tries to instantiate the concrete object, I get an exception Could not load type XXXX from assembly { separate MVC project assembly name} so it seems the model binder is unable to load types from outside its own assembly.
Can anyone give me more information on why this happens and what I can do to work around it? Bearing in mind I need the model binder and models to reside in the class library not in the MVC assembly.
I had the same problem as you did, binding to models in a different assembly, but I needed a different solution. I used the same model binding example that you linked to, and I also got the same exception: Could not load type XXXX from assembly
I ended up needing to use the AssemblyQualifiedName for each concrete type. So my views contain this:
#Html.Hidden("ModelType", Model.GetType().AssemblyQualifiedName)
Instead of this:
#Html.Hidden("ModelType", Model.GetType())
I'm still wondering why this was necessary, since the default model binder can load types from the assembly in question.
OK so I was being stupid. It turns out that a few assumptions led me on a wild goose chase.
The ModelBinder was executing correctly to start with. My viewmodel had nested properties which were also abstract base types and required the model binder but I hadn't put the hidden fields in the view to identify their concrete type, nor had I added them to the Global.asax configuration. Once I did this everything started to work as expected.
I've decided to use custom template engine with Spring MVC framework.
my templates implemented in java and have method for rendering into String:
public String render(Map context);
how to configure spring to make them available in Controller beans as views, for example like:
ModelAndView modelAndView = new ModelAndView("activationPage"); // - view name which will actually be java class name reference.
modelAndView.addObject("validationResult", validationResult);
return modelAndView;
Model will be passed as context in code connecting spring and my template engine.
You need to implement org.springframework.web.servlet.View (which should be easy, you already have something very similar to the render method it needs), as well as org.springframework.web.servlet.ViewResolver, which maps the view names (e.g. "activationPage") on your custom views.
Once you have that, drop a bean of your ViewResolver class into the context, and (unless you've done something else that gets in the way) it should automatically be picked up by Spring and should just work. if you have other ViewResolvers already in there, they may get into a fight over who gets to resolve the view, in which case ask a new question.
Hi I am the author of Rythm template engine, about half year ago I am having the same requirement like you. What I did is to read the source code of Velocity and Freemarker view of SpringFramework. And then create the Rythm view for spring following their approach.
It's easy to follow something that is already there, and it makes your implementation in good quality to follow the official module. Good luck on you :-)
As per the title, I'm seeing that my read-only model properties are not serialized in my Web API project. MVC 4 Web API, VS2010.
I've seen a multitude of posts like this stackoverflow question that state that the MVC 4 Web API beta did not support JSON serializing of read-only properties. But many additional references stated that the final release used JSON.NET instead of DataContractJsonSerializer so the issue should be resolved.
Has this issue been resolved or not? If not, am I forced to put in fake setters just to get serialization?
Correction, it does seem to work with JSON (sorry!), but XML exhibits the problem. So same question as before but in the context of XML serialization.
The default JSON serializer is now Json.NET. So readonly property serialization should work without you having to do anything at all.
For XML, in 4.5 we added this flag to the DataContractSerializer:
http://msdn.microsoft.com/en-us/library/vstudio/system.runtime.serialization.datacontractserializersettings.serializereadonlytypes.aspx
You should be able to write something like this:
config.Formatters.XmlFormatter.SetSerializer(myType, new DataContractSerializer(myType, new DataContractSerializerSettings() { SerializeReadOnlyTypes = true });
Place this code in a function called by GlobalConfiguration.Configure in the Application_Start. By default this would be WebApiConfig.Register().
Using Ninject 2 MVC 3. Correct me if i am wrong but ive seen two way of using Ninject in an MVC 3 application. We can use a new controller factory which is like ControllerBuilder.Current.SetControllerFactory(new NinjectControllerFactory()); or using NinjectHttpApplication and then configure the kernel.
I was wondering what difference between use of a controller factory and NinjectHttpApplication to configure the binding for DI?
And what are the best place to setup DI ?
NinjectHttpApplication calls ControllerBuilder.Current.SetControllerFactory(new NinjectControllerFactory()) internally.
But additionally it sets up various bindings and provides many new features. In other words it's less work and adds new features. Best you read my blog post about the MVC3 extension. http://www.planetgeek.ch/2010/11/13/official-ninject-mvc-extension-gets-support-for-mvc3/