На странице несколько слабо связанных форм. Про слабо связанную форму имеется в виду, что они не относятся к одной модели, как вложенные. При генерации моделей стандартными средствами, поле Id, которое скрытое, которое генерируется в размеку <input id="Id" name="Id" type="hidden" /> объявляется более одно раза, что приводит к невалидному коду, что собственно не так уж и критично (при раздолбайском к этому отношению), но также создает тупиковую ситуацию для скриптов, обращающихся к полям по #идентификаторам.

Есть несколько путей решения этой проблемы:
все формы сделать вложенными в единую вью-модель

генерить формы полностью ручками

создать свои темплейты, генерирующие разметку стандартыми средствами, но "убивающими" стандартную генерацию id в AdditionalHtmlAttributes, подменяя на свою (допустим ModelName + "_" + FieldName)

Что посоветует уважаемое сообщество? Как лучше?

_{все когда-нибудь начинается снова}

Парамон,

Если это массив, то проблем как раз нет, Razor генерирует правильную разметку в Html.EditorForModel(x => item)

Речь идёт о разных моделях на одной странице. Страница не привязана к конкретной модели, на ней агрегировано управление разными моделями во вкладках и всплывающих окнах. Многие формы подгружаются Ajax-ом, по мере необходимости, соответственно формы могут выдаваться разными контроллерами и разными контроллерами обрабатываться (Ajax Form). Вот и встал вопрос, как делать это по уму штатными средствами?

ShSerge,

Искренне не понимаю при чем тут транспортный протокол HTTP, какое он имеет отношение к вопросу, относящемуся к генератору представлений ASP.NET MVC Razor.

Парамон,

Некоторые. Например идентификатор объекта в любой модели это Id. Еще есть часто использующееся поле Name в разных моделях, несущее одинаковую смысловую нагрузку. Получается, что они повторяются на странице.

Поясню. Допустим, у нас есть ViewModel, содержащая два сложных поля Person и Organization. Тогда при рендеринге полей Person и Organization проблем не будет, так как сгенерируются имена типа Person_Id, Organization_Name. Это обеспечивается фреймворком. Но это самый простой практически учебный случай.

На странице может присутствовать больше форм, которые можно запихнуть во ViewModel, но не всегда нужно рендерить их сразу. Пользователю редко нужно редактировать сразу все подряд. Для этого существуют механизмы Ajax, можно во всплывающее окно отрендерить форму, если пользователю она понадобится. И форму может выдать тот контроллер, который предназначен для работы с определенными моделями. И этот контроллер ничего не знает про то, где эта форма будет отрендерена, поэтому не будет добавлять префиксы типа Person_ или Organization_. Это всего лишь один из кейсов.

На сколько я понял народ справляется с проблемой ручным управлением рендеринга типа <input type="hidden" id="item[@i].Id" name="item[@i].Id" value="@p.Id" /> без Html.EditorFor/TextBoxFor (т.е. просто напросто лишает себя стандартных механизмов валидации и правильного формат-байндинга).

ShSergehVosttShSerge,

Искренне не понимаю при чем тут транспортный протокол HTTP, какое он имеет отношение к вопросу, относящемуся к генератору представлений ASP.NET MVC Razor.
Это чисто по сабжу " Несколько форм на одной странице". Ни к какому разору это не относится.
Кстати, не мешало бы хтмл и яваскрипт подучить.

Не хочу вступать в неумный холивар, но все же вопрос относится к процессу генерирования идентификаторов стандартным движком представлений ASP.NET MVC (в данном случае, Razor), а не к тому как получить несколько форм на одной странице. Внимательно читаем топики :) Вни-ма-тель-но. И вот такие советы "подучить хтмл и яваскрипт", лучше не раздавать, если не собираетесь уточнять, что же именно в этой тематике надо мне подучить.

Deza,

если бы вы были повнимательнее и читали бы вопрос полностью, то увидили бы что об этом варианте я уже сказал (3 пункт) я спрашивал как лучше. и при чем тут name? речь идет только об идентификаторах. если вы знаете как быстрее обратить к элементам в js поделитесь открытием.

Где-то в степи,

в общем да, в селекторах можно ограничиться областью видимости формы. но. невалидно, жешь )

Deza,

если я покажу вам пример кода, вы скажете, что сюда просится нормальный такой knockout, backbone или т.п. :) и будете правы между прочим. вопрос больше теоретический. такое ощущение, что mvc проектировали сохранив остатки древней идеологии веб-формс, одна страница -- одна форма, но в более-менее вменяемом приложений количество контроллеров и вьюх на каждую модель будет зашкаливать. можно генерить код T4 или динамически, но это уже изобретение какого-то кастомного веб формс поверх mvc, значит идеального ничего не существует )) не зря telerik ушёл от своего условно-бесплатного MVC фреймворка, переключившись на js mvc и webapi.

Где-то в степи,

вот именно. id генерируется по нехитрой технологии, зависящей напрямую от имени поля (и имени родительского поля при наличии), и нет способа сказать фреймворку, как тебе нужно генерировать Id. где-то в одном месте задать свою фабрику или переопределить метод. не нравится, затыкай своим id в new { id = "мойId" } в htmlAttributes, или пиши свои темплейты на все виды типов. в общем решение есть конечно, mvc крайне расширяемый и гибкий фреймворк, вот только далеко не все предусмотрели ) хотя это все имеет смысл, если всегда стремиться использовать стандартные инструменты.

Где-то в степи,

@model ViewModel1
....
@Html.EditorForModel() — стандартно
@Html.Partial("_View2", new Model2()) — другая модель на той же странцие
@Html.Action("Edit", "Model3Controller") — при вложенном вызове контроллер отдаёт партиал, уже понимая, что его форму используют где-то в другом месте, значит нужен неймспейс в id

А вы привели пример обращение к одному и тому же свойству одной и той же модели. Конечно же в рамках одной модели хочется одинакового поведения. Если забить на валидность, то проблема как бы исчезает..

Denis2105hVostt, хотелось бы знать к какому решению ты пришел.

замена стандартных хелперов, типа Html.TextBox (и т.д.) на свои собственные, которые, кстати, по-лучше будут во всех отношениях... ну и там естественно решается проблема с правильной генерацией id