scénario fort> Dans le contrôleur, le modèle est créé sur la base du modèle de sorte que le modèle de la vue est en réalité un objet personnalisation () qui a réellement un identifiant de 0 parce qu'il est nouveau. P> dans la vue I Render @ html.Hiddenfor (m => m.Id) et la valeur résultante de cette entrée cachée est questions forte> p> y a-t-il une annotation ou quelque chose que je
peut ajouter à la méthode HTML Helper à
effectivement rendre la valeur correcte? p> li>
est-ce un bogue (MVC semble être
Rendu M.ID comme valeur de route
Indépendamment de ce que le modèle réel
est défini sur dans le contrôleur)? p> li>
ol> code supplémentaire pour clarification strong> p> solution strong> p> modification de la signature d'action à: p>
Route: / Modèle / Personnaliser / 10
Où: 10 = ID de modèle ()
/template/customize?TemplateId=10
3 Réponses :
Je pense que c'est parce que lorsque vous utilisez quelque chose comme Vous pouvez donc changer votre itinéraire afin que ce soit quelque chose comme ou vous pouvez modifier votre viewModel (ou créer un modèle de vue personnalisé) qui possède une propriété Et non, ce n'est pas un bug ... C'est plus une fonctionnalité qui peut avoir des conséquences imprévues. Mais une fois que vous êtes au courant, cela fonctionne comme un régal. @ html.hiddacfor (m => m.Id) Les aides HTML examinent dans divers endroits pour remplir la valeur de l'entrée et les valeurs dans le route est l'un de ces endroits.
modèle / personnalisation / {templateid} et ensuite votre méthode d'action reflète ceci, par exemple. ActionSResulte publique Personnaliser (int templateid) .
personnalisation propriété plutôt que simplement ID . .
Je me rends compte que je me penche probablement les règles et en casser quelques-uns aussi bien. Sentant définitivement la douleur de cela, mais je me sens toujours comme M.ID devrait toujours être le modèle.Id Pas la route.Id à moins que le modèle n'existe pas dans le contexte.
Vous me conduisez à une solution acceptable, donc je marquais votre réponse. Suivi avec une édition contenant ce que j'ai fait.
Je veux juste clarifier, que l'une de vos autres solutions aurait également travaillé (et que la route aurait été plus élégante). Je ne voulais tout simplement pas créer un nouvel itinéraire dans ma table de route.
Pourquoi pourquoi pourquoi a-t-il une valeur d'un itinéraire plutôt que d'un élément sur une forme? Sachez-vous où je peux en savoir plus à ce sujet? Merci
J'achète cela comme une fonctionnalité si vous utilisez un modèle dactylographié dactylographié, mais ce n'est pas le cas. Vous ne pourrez même pas ajouter de masqué à un autre paramètre d'itinéraire car le cachissement s'attendra à une expression qui retourne une mémorisation de la membéré pointant vers une propriété du type de modèle. Par exemple, vous ne pourrez pas faire HTML.HÉDITDOR (x => x.controller)
J'ai l'impression que ceci est un bug. Si j'utilise une vue fortement typée, je m'attendrais à ce que Model => Model.ID soit exactement un endroit pour l'ID qui étant le modèle de vue.
Vous pouvez toujours choisir de ne pas utiliser l'aide HTML dans ce cas et utilisez plutôt HTML HTML:
Pour empêcher les valeurs de route de remplacer les propriétés correspondantes du modèle, appelez modelstate.clear () code> dans votre action de contrôleur. Soyez prudent d'appeler cette méthode après em> en utilisant / lisant l'état modèle. public ActionResult Customize( int id )
{
var template = Persistence.Data.RetrieveObject<Template>( id );
var model = new Customization();
ViewBag.Template = template;
this.ViewData.ModelState.Clear(); // add that after you consume the ModelState
return ( View( model ) );
}
Pourriez-vous s'il vous plaît montrer du code? Contrôleur et vue seraient utiles. On dirait que votre point de vue peut être hérité du mauvais type de modèle.
Ajouté du code. La vue utilise le bon type pour le modèle. Comme Charlino identifie, ce n'est probablement pas un bogue, mais une conséquence. Le problème est que cette conséquence enfreint l'automatisation.