I have a BookCreateModel which consists of book's plane info such as Title, PublishYear & etc plus a collection of book Authors (complex type) :
public class BookCreateModel
{
public string Title { get; set; }
public int Year { get; set; }
public IList<AuthorEntryModel> Authors { get; set; }
}
public class AuthorEntryModel
{
public string FirstName { get; set; }
public string LastName { get; set; }
}
in CreateBook view I have used EditorFor
helper :
@Html.EditorFor(m => m.Authors, "AuthorSelector")
Edit1:
and AuthorSelector template is as below:
<div class="ptr_authors_wrapper">
@for (int i = 0; i < Model.Count; i++)
{
<div class="ptr_author_line" data-line-index="@i">
@Html.TextBoxFor(o => o[i].FirstName)
@Html.TextBoxFor(o => o[i].LastName)
</div>
}
</div>
<script>
...
</script>
the AuthorSelector
template contains some wrapper markups which need to be aware of each rendered item's index plus some javascript which handle the child input's interactions and need to be rendered once (inside the AuthorSelector
template), thus getting rid of the for loop/or the AuthorSelector template is not possible.
now the problem is EditorFor act a little strange and generate input names like this :
<input id="Authors__0__FirstName" name="Authors.[0].FirstName" type="text" value="" />
<input id="Authors__0__LastName" name="Authors.[0].LastName" type="text" value="" />
as you can see instead of generating names like Authors[0].FirstName
it adds an extra dot which makes the default model binder unable to parse posted data.
any idea ?
Thanks !
I'm a little late to the party, but hopefully this helps someone.
Digging down to
System.Web.Mvc.Html.DefaultEditorTemplates.CollectionTemplate(HtmlHelper html, TemplateHelpers.TemplateHelperDelegate templateHelper)
, the framework's default template handles this by temporarily setting theHtmlFieldPrefix
to an empty string and explicitly passing the prefix and index into a call toEditorFor()
.I found this particularly useful when the framework was writing names as
[0].Children.[0].ChildProperty
due to a named template for the Children collection. In my case, the solution was to call:rather than simply calling:
I would recommend you sticking to conventions, i.e. replace:
with:
and then rename your
~/Views/Shared/EditorTemplates/AuthorSelector.cshtml
to~/Views/Shared/EditorTemplates/AuthorEntryModel.cshtml
and make it strongly typed to a singleAuthorEntryModel
model and get rid of the loop:ASP.NET MVC will automatically render the editor template for all elements of the collection and generate proper names.
UPDATE:
After seeing your update here's my response:
In your main view:
In your editor template:
You will notice the absence of script in the template which is perfectly normal. Scripts have nothing to do in markup. They go into separate javascript files. In this file you could use jQuery to do whatever you need to do with your markup. It gives you methods such as
.index()
that allow you to get the index of the element in the matched selector so that you don't need to write any loops and pollute your markup with things likedata-line-index
attributes.Here's an extension method you can use which will render a partial view and use the correct HTML field prefix:
Extension Method
Sample Usage
I didn't find any solution to this bug yet, but as a workaround I changed my
UpdateModel
by using a custom wrapper class instead of using a collection directly :and thus generated inputs wouldn't make naming issues anymore :)
Don't know if it's still relevant, but this blog covers a solution to your problem: http://btburnett.com/2011/03/correcting-mvc-3-editorfor-template-field-names-when-using-collections.html
--> Credits go to itsmatt for finding it :) Jakob
I stumbled upon this when I was trying to find the solution for pretty much the same issue. My workaround was to kick the can down the road, ie. make wrapper model for the collection and use that in the editor template. In provided case, it would be:
Then rename your editor template to "BookAuthorsModel.cshtml" and make it like this:
And when you want to use it, simply call:
It should then generate input fields like so:
In my case I also changed Automapper mapping settings appropriately Controller code. This is not usable for some more complex scenarios however and is thus probably just a workaround.