Es geht um folgende Ansicht:
@model List<UserRoleViewModel>
@{
var roleId = ViewBag.roleId;
}
<form method="post">
<div class="card">
<div class="card-header">
<h2>Add or remove users from this role</h2>
</div>
<div class="card-body">
@for (int i = 0; i < Model.Count; i++)
{
<div class="form-check m-1">
<input type="hidden" asp-for="@Model[i].UserId" />
<input type="hidden" asp-for="@Model[i].UserName" />
<input asp-for="@Model[i].isSelected" class="form-check-input" />
<label class="form-check-label" asp-for="@Model[i].isSelected">
@Model[i].UserName
</label>
</div>
}
</div>
<div class="card-footer">
<input type="submit" value="Update" class="btn btn-primary"
style="width:auto" />
<a asp-action="EditRole" asp-route-id="@roleId"
class="btn btn-primary" style="width:auto">Cancel</a>
</div>
</div>
</form>
Wenn ich nun die For-Schleife durch folgende foreach Schleife ersetze, erhalte ich als Model eine leere Liste. Was soll das? Sollte die Wahl der Schleife nicht egal sein, solange ich die Indexes nicht brauche???
@foreach (var vm in Model)
{
<div class="form-check m-1">
<input type="hidden" asp-for="@vm.UserId" />
<input type="hidden" asp-for="@vm.UserName" />
<input asp-for="@vm.isSelected" class="form-check-input" />
<label class="form-check-label" asp-for="@vm.isSelected">
@vm.UserName
</label>
</div>
}
Wie es der Zufall wollte, kam heute Abend (im Rahmen der Reihe, wo der Fehler auftrat) die Erklärung:
Bei dem Problem handelt es sich um eine fehlerhafte Implementierung des Razor Interpreters (oder wie auch immer man das Ding nun nennt):
Bei Checkboxes verwendet er die Indizes der For Schleife als eindeutige Indikatoren, um die Feldnamen unique zu machen.
Bei Foreach fehlen ihm diese Indizes, und ASP.NEt Core kann kein Model bilden, auf Grund redundanter Feldnamen.
Eigentlich unnötig, denn auch wenn foreach keine Indizes hat, so kann man doch beim PARSEN dieser Razor foreach Schleife intern einfach einen Counter mitlaufen lassen, und das Problem wäre aus der Welt ...
Hoffe Microsoft fixed diesen Issue erstmal, bevor man wieder neue Versionen raushaut ...
Hier das Video dazu:
https://www.youtube.com/watch?v=Qobkh8gEP6Q&feature=youtu.be
foreach Schleifen laufen über einen Iterator, die kennen keinen Counter in der Form.
Die wissen nur ob Sie am Ende sind oder nicht.
Wenn dies von MS noch nicht behoben wurde, dann dürfte dies auch genau daran liegen und vermutlich auch ein Konzept Fehler o.ä. sein.
Ich vermute mal, dass dieses Verhalten aber dokumentiert sein dürfte.
T-Virus
Developer, Developer, Developer, Developer....
99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.
das ist mir klar, nur handelt es sich bei Razor Schleifen um 'simulierte' Schleifen, wo in der Implementierung durch das Framework, ja durchaus ein Zähler mitlaufen könnte.
Wo ist denn die Stelle, die besagt, dass es am Razor Interpreter liegt?
Schon in ASP.NET MVC hätte man das foreach
normalerweise nicht in der Form entwickelt.
Ich konnte jetzt auf die Stelle nichts in GitHub dazu finden, das diesen "Fehler" bestätigen würde.
ASP.NET Core 3 Preview 8 (aktuellste Variante) verhält sich jedenfalls genauso.
Kann mich jetzt schlecht vorstellen, dass das hier nicht gefixt wäre, sofern es ein Bug wäre - und es bisher niemand aufgefallen wäre.
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code
Naja, ich sehe das halt wie folgt:
Es ist doch der Sinn der sog. Tag Helper und des ASP-Frameworks, dass ich mir keine Gedanken über das HTML machen muss, bzw. mich auf die reine Logik konzentrieren kann, die Feinarbeit aber im Hintergrund passiert.
Klar, wenn man sich der Notwendigkeit von der For-Schleife bewusst ist, dann ist es logisch, aber kennt man sie nicht, ist sie ja nicht sofort offensichtlich.
Es ist doch der Sinn der sog. Tag Helper und des ASP-Frameworks, dass ich mir keine Gedanken über das HTML machen muss,
Nein, das ist nicht der primäre Sinn.
Der Sinn von TagHelpern ist es, dass das Generieren von HTML erleichtert wird - es nimmt Dir nicht das Denken ab.
Es nennt sich auch HTML friendly developer experience.
Bei dem Problem handelt es sich um eine fehlerhafte Implementierung des Razor Interpreters
Würde mich trotzdem interessieren, woher dieses Fazit kommt. Im Video finde ichs nicht.
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code