Две типовых проблемы:
1. Как правильно сделать "Post-Redirect-Get"?
Более подробно: есть две страницы A.mvc и C.mvc и три метода в контроллере A(), B(), C().
Методы A() отдает вьюху с формой, метод C() успешный результат post'а формы.
На метод B() post'ятся данные формы.
Алгоритм работы:
1) Переходим на A.mvc — рендерится форма.
2) Пользователь забивает поля формы и постит на B().
3) В B() происходит серверная валидация и если
результат отрицательный, то редирект на A() с сохранением состояния модели, чтобы отрендерить ошибки валидации;
если результат валидации положительный, то редирект на C().
В стандартном MVC не нашел средств упрощающих такую реализацию, а в MvcContrib реализация не логичная на мой взгляд,
поэтому написал пока пару своих фильтров для сохранения/загрузки модели, но приходится перед редиректом на C() очищать
состояние модели в Temp'е, иначе после C() пользователь может перейти на A() и увидеть старые ошибки валидации.
В общем, простого и лаконичного решения я не нашел.
Покажите, пожалуйста, образцовый код, который делает это минимумом движений.

2. Есть модель формы, по которой нужно генерировать кастомную (в каждом проекте) разметку.
Хочется на каждый тип проперти модели написать фрагмент верстки и отдавать на рендеринг просто объект модели, а вся работа по
генерации нужной верстки проходила бы "за сценой".
Сюда же хочется возможность прикрутить клиентскую валидацию по серверный атрибутам модели.

зы Может вопросы и детские, но я уже замучался гуглить.

А ты не усложняешь всё, случаем?

RPG обычно делается так:

[HttpGet]
public ActionResult A()
{
   return View(new Model());
}

[HttpPost]
public ActionResult A(Model model)
{
   if(!ModelState.IsValid)
       return View(model);

   return RedirectToAction(MVC.ThisController.C);
}

[HttpGet]
public ActionResult C()
{
   return View();
}

Если очень надо, чтобы имя Action'а куда постим отличалось от А, то вместо

return View(model)

пишем

return View("A", model)

Здравствуйте, Ocenochka, Вы писали:

O> Две типовых проблемы:
O> 1. Как правильно сделать "Post-Redirect-Get"?
O> Более подробно: есть две страницы A.mvc и C.mvc и три метода в контроллере A(), B(), C().
O> Методы A() отдает вьюху с формой, метод C() успешный результат post'а формы.
O> На метод B() post'ятся данные формы.
O> Алгоритм работы:
O> 1) Переходим на A.mvc — рендерится форма.
O> 2) Пользователь забивает поля формы и постит на B().
O> 3) В B() происходит серверная валидация и если
O> результат отрицательный, то редирект на A() с сохранением состояния модели, чтобы отрендерить ошибки валидации;
O> если результат валидации положительный, то редирект на C().
O> В стандартном MVC не нашел средств упрощающих такую реализацию, а в MvcContrib реализация не логичная на мой взгляд,
O> поэтому написал пока пару своих фильтров для сохранения/загрузки модели, но приходится перед редиректом на C() очищать
O> состояние модели в Temp'е, иначе после C() пользователь может перейти на A() и увидеть старые ошибки валидации.
O> В общем, простого и лаконичного решения я не нашел.
O> Покажите, пожалуйста, образцовый код, который делает это минимумом движений.

O>2. Есть модель формы, по которой нужно генерировать кастомную (в каждом проекте) разметку.
O> Хочется на каждый тип проперти модели написать фрагмент верстки и отдавать на рендеринг просто объект модели, а вся работа по
O> генерации нужной верстки проходила бы "за сценой".
O> Сюда же хочется возможность прикрутить клиентскую валидацию по серверный атрибутам модели.

O>зы Может вопросы и детские, но я уже замучался гуглить.

Здравствуйте, Маслаков Михаил, Вы писали:

ММ>А ты не усложняешь всё, случаем?

Не исключено

ММ>RPG обычно делается так:

ММ>

ММ>[HttpGet]
ММ>public ActionResult A()
ММ>{
ММ>   return View(new Model());
ММ>}

ММ>[HttpPost]
ММ>public ActionResult A(Model model)
ММ>{
ММ>   if(!ModelState.IsValid)
ММ>       return View(model);

ММ>   return RedirectToAction(MVC.ThisController.C);
ММ>}

ММ>[HttpGet]
ММ>public ActionResult C()
ММ>{
ММ>   return View();
ММ>}
ММ>

Хм, действительно, так гораздо проще
Только получается, что после не валидного поста, рендеринга формы с валидационными сообщениями
можно исправить форму, а потом нажать F5 (browser.refresh) и получить во-первых сообщение-подтверждение браузера о повторной
отправке, а во-вторых после отправки будут предыдущие ошибки валидации, не смотря на изменения полей формы, но это я наверно уже придираюсь.
Спасибо, попробую такой вариант.

Здравствуйте, Ocenochka, Вы писали:

O>2. Есть модель формы, по которой нужно генерировать кастомную (в каждом проекте) разметку.
O> Хочется на каждый тип проперти модели написать фрагмент верстки и отдавать на рендеринг просто объект модели, а вся работа по
O> генерации нужной верстки проходила бы "за сценой".
O> Сюда же хочется возможность прикрутить клиентскую валидацию по серверный атрибутам модели.

Data annotations
Html.EditorForModel, Html.DisplayForModel

Здравствуйте, Ocenochka, Вы писали:
O> Только получается, что после не валидного поста, рендеринга формы с валидационными сообщениями
O> можно исправить форму, а потом нажать F5 (browser.refresh) и получить во-первых сообщение-подтверждение браузера о повторной
O> отправке, а во-вторых после отправки будут предыдущие ошибки валидации, не смотря на изменения полей формы, но это я наверно уже придираюсь.
O> Спасибо, попробую такой вариант.

Попробуйте както так, мои добавления выделены жирным

ММ>>

[HttpGet]
public ActionResult A()
{
   var model = TempData["mymodel"] != null ? ((Model) TempData["mymodel"]) : new Model(); 
   return View(model);
}

[HttpPost]
public ActionResult A(Model model)
{
   if(!ModelState.IsValid)
   {
       TempData["mymodel"] = this.ModelState;
       return RedirectToAction(MVC.ThisController.A);
   }

   
   return RedirectToAction(MVC.ThisController.C);
}

[HttpGet]
public ActionResult C()
{
   var model = TempData["model"];
   return View(model);
}

Теперь в случае, если валидация не пройдена, пользователя будет перекидывать обратно на A, сохраняя при этом данные.

Здравствуйте, Ocenochka, Вы писали:

O> Хм, действительно, так гораздо проще
O> Только получается, что после не валидного поста, рендеринга формы с валидационными сообщениями
O> можно исправить форму, а потом нажать F5 (browser.refresh) и получить во-первых сообщение-подтверждение браузера о повторной
O> отправке, а во-вторых после отправки будут предыдущие ошибки валидации, не смотря на изменения полей формы, но это я наверно уже придираюсь.
O> Спасибо, попробую такой вариант.

В предыдущей моем посте были ошибки.
В общем вот, только что добавил в свой проект

        /// <summary>
        /// Get the view of document creation.
        /// </summary>
        /// <returns>The view of document creation.</returns>
        public ActionResult Create()
        {
            if(TempData["ModelState"] != null)
            {
                var state = (ModelStateDictionary) TempData["ModelState"];
                this.ModelState.Clear();
                foreach(var item in state)
                    this.ModelState.Add(item);
            }
            return View();
        }

        /// <summary>
        /// Creates the new record for document in the storage.
        /// </summary>
        /// <param name="document">The document.</param>
        /// <returns></returns>
        [HttpPost]
        public ActionResult Create(Document document)
        {
            if (ModelState.IsValid)
            {
                try
                {
                    var id = _repository.Create(document);
                    return RedirectToAction("Index");
                }
                catch
                {
                    TempData["ModelState"] = this.ModelState;
                    return RedirectToAction("Create");
                }
            }
            else
            {
                TempData["ModelState"] = this.ModelState;
                return RedirectToAction("Create");
            }
        }

Есть два экшена Create. Один для GET, второй для POST. При отправке формы происходит переход на POST версию Create.
Если данные валидны, то идет редирект на Index, если невалидны, то переходим на GET версию Create и восстанавливаем форму и сообщения об ошибках.

Здравствуйте, Ocenochka, Вы писали:

O> Хм, действительно, так гораздо проще
O> Только получается, что после не валидного поста, рендеринга формы с валидационными сообщениями
O> можно исправить форму, а потом нажать F5 (browser.refresh) и получить во-первых сообщение-подтверждение браузера о повторной
O> отправке, а во-вторых после отправки будут предыдущие ошибки валидации, не смотря на изменения полей формы, но это я наверно уже придираюсь.

несколько тезисов:
* Post надо делать _только_ через Ajax.
* при этом показывать "крутяшку"
* назад прилетает :
** либо структура с ошибками ( например те которые нельзя просто проверить на клиенте )
** либо разрешение сделать редирект( напрмиер просто url )

Здравствуйте, mogadanez, Вы писали:

M>несколько тезисов:
M>* Post надо делать _только_ через Ajax.
Вообще всегда и везде?
А если с яваскриптом у клиента проблемы? Вообще известен процент пользователей в инете без яваскрипта?

M>>несколько тезисов:
M>>* Post надо делать _только_ через Ajax.
IB>Вообще всегда и везде?

ИМХО — да в разы повышает дружественность интерфейса и скорость работы.

IB>А если с яваскриптом у клиента проблемы?

запасной вариант в виде обычного поста при этом тоже может быть.
а делать его поддержку или нет — решение персональное, зависит от сайта и целевой аудитории.

если у меня сайт "интерактивный", и ежу понятно что без яваскрипта на нем прибывать это все равно что рассматривать фотографии в notepad'е — то я бы забил на поддержку пользователей без скрипта.
да и вообще сходу мне сложно придумать сайт в котором — а) есть ввод данных а не просто чтение( т.е. новостные ленты не канают ) б) _важно_ сохранить людей у которых отключен яваскрипт

IB>Вообще известен процент пользователей в инете без яваскрипта?
http://www.w3schools.com/browsers/browsers_stats.asp
в 2008 — 5%( сколько из них настоящих пользователей а не всякх роботов — ХЗ )
сейчас я думаю 1% или меньше.

Здравствуйте, mogadanez, Вы писали:

O>> Хм, действительно, так гораздо проще
O>> Только получается, что после не валидного поста, рендеринга формы с валидационными сообщениями
O>> можно исправить форму, а потом нажать F5 (browser.refresh) и получить во-первых сообщение-подтверждение браузера о повторной
O>> отправке, а во-вторых после отправки будут предыдущие ошибки валидации, не смотря на изменения полей формы, но это я наверно уже придираюсь.

M>несколько тезисов:
M>* Post надо делать _только_ через Ajax.
M>* при этом показывать "крутяшку"
M>* назад прилетает :
M> ** либо структура с ошибками ( например те которые нельзя просто проверить на клиенте )
M> ** либо разрешение сделать редирект( напрмиер просто url )

Что-то какой-то сложный вариант — много яваскрипта.
А почему "Post надо делать _только_ через Ajax" ?

Здравствуйте, Ocenochka, Вы писали:

O> Что-то какой-то сложный вариант — много яваскрипта.

в современном мире это нормально.

O> А почему "Post надо делать _только_ через Ajax" ?

причин много, самая главная — лучше user expirience

Здравствуйте, SE, Вы писали:

SE>В предыдущей моем посте были ошибки.
SE>В общем вот, только что добавил в свой проект
SE>

 SKIP
SE>

У меня почти такое же решение, только на фильтрах с атрибутами.
Не нравится мне эта громозкость — больше понравилось решение Маслакова Михаила выше в этой ветке.
И недостаток с F5 не такой критичный, а больше проблем я не вижу.

Здравствуйте, mogadanez, Вы писали:

O>> Что-то какой-то сложный вариант — много яваскрипта.
M>в современном мире это нормально.

Да уж, если и на сервере javascript используют, то чего уж говорить...

O>> А почему "Post надо делать _только_ через Ajax" ?
M>причин много, самая главная — лучше user expirience

Не могли бы Вы поподробнее описать что значит "лучше user expirience"?
Кроме того, что пользователь увидит крутилку.

Здравствуйте, Ocenochka, Вы писали:

O>Здравствуйте, mogadanez, Вы писали:


O> Не могли бы Вы поподробнее описать что значит "лучше user expirience"?
O> Кроме того, что пользователь увидит крутилку.

1. меньший объем данных туда сюда — быстрее
2. нет моргания( перерисовки страницы ) — приятнее
3. меньше шансов потерять введенные данные, по причине недоступности сервера на Пост запрос — круто
4. появляются совершенно новые возможности которые просто не укладываются в концепцию поста всей страницы целиком например — редактирование каких то кусков страницы на лету и т.д.
5. крутилка =)

+ субъективно сделать "красиво" чтобы подсветились поля с ошибками, было саммари с линками на ошибочные поля, и т.д. — проще на Javascript чем кучей условий при рендере вьюхи

Здравствуйте, mogadanez, Вы писали:

O>> Не могли бы Вы поподробнее описать что значит "лучше user expirience"?
O>> Кроме того, что пользователь увидит крутилку.

M>1. меньший объем данных туда сюда — быстрее

Самое медленное в этой процедуре — это запрос от пользователя на сервер, объемы — принебрежимо малы.
Запрос происходит в обоих случаях => вряд ли с ajax'ом ощутимо быстрее.

M>2. нет моргания( перерисовки страницы ) — приятнее

Но так и пользователю сложнее заметить, что ответ пришел.
И вообще, мигание не так ужасно и по-моему к нему все привыкли.
В общем точно не аргумент писать лишний код и поддерживать его.

M>3. меньше шансов потерять введенные данные, по причине недоступности сервера на Пост запрос — круто

И что вы будете делать с введенными данными, если сервер не доступен?

M>4. появляются совершенно новые возможности которые просто не укладываются в концепцию поста всей страницы целиком например — редактирование каких то кусков страницы на лету и т.д.

С аяком ломается навигация страниц и пользователи оказываются дизориентированы.
Аякс хорош, когда его мало (изюранное отметить или проголосовать) и он не перерисовывает большую часть страницы.
Навигация должна быть без аякса до тех пор, пока нельзя будет прикрутить ajax-движок, который бы подставлял правильные значения после '#' в адресную строку, чтобы навигация то же работала, как ожидается.

M>5. крутилка =)

Её и браузер покажет

M>+ субъективно сделать "красиво" чтобы подсветились поля с ошибками, было саммари с линками на ошибочные поля, и т.д. — проще на Javascript чем кучей условий при рендере вьюхи

Куча условий будет если не на сервере, то на клиенте — от них никуде не деться, остальное не имеет отношения к яваскрипту и делается так же, как и при post'е.
Признайтесь, Вам нравится писать на javascript'е?

Здравствуйте, Ocenochka, Вы писали:

M>>1. меньший объем данных туда сюда — быстрее

O> Самое медленное в этой процедуре — это запрос от пользователя на сервер, объемы — принебрежимо малы.
O> Запрос происходит в обоих случаях => вряд ли с ajax'ом ощутимо быстрее.

по практике не сказал бы, назад летит 150к хтмля или 5к json'a разница по времени есть.
к тому же браузер новую разметку будет заново перерисовывать
да даже серверный код отрабатывает быстрее потому что контур рендера пропускается вообще даже 0.5 сек тут существенный выигрыш

По практике время через которое пользователь может сделать чтото новое сокращается в 3-4 раза.


M>>2. нет моргания( перерисовки страницы ) — приятнее

O> Но так и пользователю сложнее заметить, что ответ пришел.

Крутилка была и ее не стало, если валидация случилась поля подстветились, и т.д

O> И вообще, мигание не так ужасно и по-моему к нему все привыкли.
O> В общем точно не аргумент писать лишний код и поддерживать его.

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


M>>3. меньше шансов потерять введенные данные, по причине недоступности сервера на Пост запрос — круто
O> И что вы будете делать с введенными данными, если сервер не доступен?

они останутся в полях, будет сообщение что "сервер недоступен попробуйте позже" и пользователь может опять нажать Save =) гораздо очевиднее чем диалог который выскочит по f5


M>>4. появляются совершенно новые возможности которые просто не укладываются в концепцию поста всей страницы целиком например — редактирование каких то кусков страницы на лету и т.д.

O> С аяком ломается навигация страниц и пользователи оказываются дизориентированы.
O> Аякс хорош, когда его мало (изюранное отметить или проголосовать) и он не перерисовывает большую часть страницы.
O> Навигация должна быть без аякса до тех пор, пока нельзя будет прикрутить ajax-движок, который бы подставлял правильные значения после '#' в адресную строку, чтобы навигация то же работала, как ожидается.

а про навигацию я не говорил и не предлагал, я в основном про маленькие сценарии, а главное что паттерн Post-Redirect-Get должен со временем трансформироватся в AjaxPost-Redirect-Get


O> Куча условий будет если не на сервере, то на клиенте — от них никуде не деться, остальное не имеет отношения к яваскрипту и делается так же, как и при post'е.

При классическом Post-Redirect-Get есть один тонкий, я бы сказал на волосе висящий ньюанс — Валидация.
Что делать если данные не верны? нам нужно отрендерить форму заново, подсветить все ошибки, сохранив данные в полях.

как и было с самого начала топика озвучено — варианта в общем два.
1. вернуть данные прямо в ответ на Post. проблемы понятны:
1.1 гребаный F5
1.2 нужно востановить старые значения в инпутах, как их ввел пользователь, даже если обламался ModelBinding ( например в числовое поле пишем строку )
в MVC архитектуре пришлось для этого делать дополнительное приседание в виде ModelState, который кстати удобно использовать только если юзаешь стандартные HtmlHelper'ы — в случае plain разметки полный гемор

2. честный Post-Redirect-Get, когда даже при ошибке валидации мы делаем редирект и как-то передаем туда данные, тут все вроде ничего, кроме самой передачи:
2.1 — самый "правильный" способ передать все прямо в урле при редиректе, но в реальной жизни практически не применим, разве что в некоторых совсем простых случаях.
2.2 — TempData — это конечно пц скажу я вам. во первых, они используют всегда один ключ, и пользователь работающий в нескольких вкладках имеет шанс получить облом. во вторых в случае

итого — для работы в "старом" сценарии нужны технические костыли.
в том о чем говорю я все более естесвенно, загрузилась форма(по сути сама она клиент серверное приложение десктопное, ничем не отличается ), она _сама_ провела перичную валидацию, и если ок, послала запрос на сервер.
сервер не делает лишнего, обрабатывает то что прислали и говорит ок/не_ок+детали_что_не_ок. форма получила ответ, адеватно отреагировала, если надо передала управление другой форме( редирект )

O> Признайтесь, Вам нравится писать на javascript'е?

Да, вполне.

Здравствуйте, mogadanez, Вы писали:

O>> Самое медленное в этой процедуре — это запрос от пользователя на сервер, объемы — принебрежимо малы.
O>> Запрос происходит в обоих случаях => вряд ли с ajax'ом ощутимо быстрее.
M>по практике не сказал бы, назад летит 150к хтмля или 5к json'a разница по времени есть.

Если разница по времени существенная, то явно надо что-то делать, и я бы начал с уменьшения размера страницы. В эти 150кб ведь не входят скрипты, css и картинки — только html?

M>к тому же браузер новую разметку будет заново перерисовывать

Про мерцание видимо ниже

M>да даже серверный код отрабатывает быстрее потому что контур рендера пропускается вообще даже 0.5 сек тут существенный выигрыш

Откуда известно на на рендер 0.5 сек? Я в этом сильно сомневаюсь.

M>По практике время через которое пользователь может сделать чтото новое сокращается в 3-4 раза.

Ого, это из-за отсутствия рендера? Или из-за сокращения содержимого сообщения со 150 до 5 килобайт?

M>>>2. нет моргания( перерисовки страницы ) — приятнее
O>> Но так и пользователю сложнее заметить, что ответ пришел.
M>Крутилка была и ее не стало, если валидация случилась поля подстветились, и т.д

Поля и после перерисовки подсветятся, хотя если отрисовка страницы занимает время, то заметить будет сложнее — согласен.

O>> И вообще, мигание не так ужасно и по-моему к нему все привыкли.
O>> В общем точно не аргумент писать лишний код и поддерживать его.
M>Еще какой аргумент. Как привыкли так и быстро отвыкают в свете все большего количества сайтов с аяксом, сайты без него пользователям кажутся реально устаревшими.

Сложно спорить, думаю Вы правы, хотя отсутствие фактов, подтверждающих это делает этот аргумент не достаточным, не учитывая остальные, которые я еще до конца не сравнил )

M>>>3. меньше шансов потерять введенные данные, по причине недоступности сервера на Пост запрос — круто
O>> И что вы будете делать с введенными данными, если сервер не доступен?
M>они останутся в полях, будет сообщение что "сервер недоступен попробуйте позже" и пользователь может опять нажать Save =) гораздо очевиднее чем диалог который выскочит по f5

Ладно, тут то же согласен и потеря данных — это уже значительный аргумент.

O>> Навигация должна быть без аякса до тех пор, пока нельзя будет прикрутить ajax-движок, который бы подставлял правильные значения после '#' в адресную строку, чтобы навигация то же работала, как ожидается.
M>а про навигацию я не говорил и не предлагал, я в основном про маленькие сценарии, а главное что паттерн Post-Redirect-Get должен со временем трансформироватся в AjaxPost-Redirect-Get

Как же найти эту грань? Если на странице вкладки, то перемещение по ним делать яваскриптом?

O>> Куча условий будет если не на сервере, то на клиенте — от них никуде не деться, остальное не имеет отношения к яваскрипту и делается так же, как и при post'е.

M>При классическом Post-Redirect-Get есть один тонкий, я бы сказал на волосе висящий ньюанс — Валидация.
M> Что делать если данные не верны? нам нужно отрендерить форму заново, подсветить все ошибки, сохранив данные в полях.

M>как и было с самого начала топика озвучено — варианта в общем два.
M>1. вернуть данные прямо в ответ на Post. проблемы понятны:
M> 1.1 гребаный F5
M> 1.2 нужно востановить старые значения в инпутах, как их ввел пользователь, даже если обламался ModelBinding ( например в числовое поле пишем строку )
M> в MVC архитектуре пришлось для этого делать дополнительное приседание в виде ModelState, который кстати удобно использовать только если юзаешь стандартные HtmlHelper'ы — в случае plain разметки полный гемор

А откуда могут появится ограничения на использование HtmlHelper'ов?
Хотя то, что они — "лишнее приседание" должен согласиться.

M>2. честный Post-Redirect-Get, когда даже при ошибке валидации мы делаем редирект и как-то передаем туда данные, тут все вроде ничего, кроме самой передачи:
M> 2.1 — самый "правильный" способ передать все прямо в урле при редиректе, но в реальной жизни практически не применим, разве что в некоторых совсем простых случаях.
M> 2.2 — TempData — это конечно пц скажу я вам. во первых, они используют всегда один ключ, и пользователь работающий в нескольких вкладках имеет шанс получить облом. во вторых в случае

Можно поподробнее, один ключ на что? На один тип модели?

M>итого — для работы в "старом" сценарии нужны технические костыли.
M>в том о чем говорю я все более естесвенно, загрузилась форма(по сути сама она клиент серверное приложение десктопное, ничем не отличается ), она _сама_ провела перичную валидацию, и если ок, послала запрос на сервер.
M>сервер не делает лишнего, обрабатывает то что прислали и говорит ок/не_ок+детали_что_не_ок. форма получила ответ, адеватно отреагировала, если надо передала управление другой форме( редирект )

В общем — да, согласен.
Только как же в таком случае делать валидацию?
В двух местах писать и поддерживать одну логику валидации иди писать свой генератор клиентского яваскрипта валидации, если хочется на одном jquery без микрософтовского яваскриптовой библиотеки?

O>> Признайтесь, Вам нравится писать на javascript'е?
M>Да, вполне.
Мне как-то не удобно дебажить в браузере в маленькой панельке или в маленьком окошке — надо наверно задуматься о втором мониторе


ps Можете подкинуть примерчик какого-нибудь открытого проекта, в котором можно посмотреть как минимумом действий делается обсуждаемый сценарий на asp.net mvc? А то свои велосипеды изобретать слишком затратно, а спросить не у кого )

Здравствуйте, Ocenochka, Вы писали:

O>Здравствуйте, mogadanez, Вы писали:

M>>По практике время через которое пользователь может сделать чтото новое сокращается в 3-4 раза.

O> Ого, это из-за отсутствия рендера? Или из-за сокращения содержимого сообщения со 150 до 5 килобайт?

суммарно, через сколько пользователь может сделать следую после нажатия Save операцию.

O>>> Навигация должна быть без аякса до тех пор, пока нельзя будет прикрутить ajax-движок, который бы подставлял правильные значения после '#' в адресную строку, чтобы навигация то же работала, как ожидается.
M>>а про навигацию я не говорил и не предлагал, я в основном про маленькие сценарии, а главное что паттерн Post-Redirect-Get должен со временем трансформироватся в AjaxPost-Redirect-Get

O> Как же найти эту грань? Если на странице вкладки, то перемещение по ним делать яваскриптом?

depends. вкладки бывают разные. сверху разделы сайта — одназначно разные урлы. а например на странице конфигурации вкладки General, Advanced — "локальные"

M>> 1.2 нужно востановить старые значения в инпутах, как их ввел пользователь, даже если обламался ModelBinding ( например в числовое поле пишем строку )
M>> в MVC архитектуре пришлось для этого делать дополнительное приседание в виде ModelState, который кстати удобно использовать только если юзаешь стандартные HtmlHelper'ы — в случае plain разметки полный гемор

O> А откуда могут появится ограничения на использование HtmlHelper'ов?
потому что без них ацки много кода. тебе нужно руками смотреть и в ModelState на предмет ошибок и в саму модель, и брать значение для поля либо оттуда либо оттуда.
O> Хотя то, что они — "лишнее приседание" должен согласиться.

M>>2. честный Post-Redirect-Get, когда даже при ошибке валидации мы делаем редирект и как-то передаем туда данные, тут все вроде ничего, кроме самой передачи:
M>> 2.1 — самый "правильный" способ передать все прямо в урле при редиректе, но в реальной жизни практически не применим, разве что в некоторых совсем простых случаях.
M>> 2.2 — TempData — это конечно пц скажу я вам. во первых, они используют всегда один ключ, и пользователь работающий в нескольких вкладках имеет шанс получить облом. во вторых в случае

O> Можно поподробнее, один ключ на что? На один тип модели?

вообще один, для каждой сессии пользователя. расчет идет только на то что все происходит очень быстро =) и третий( четвертый,пятый ) запрос не сумеет вклинится между запросом который положил данные в Temp и который их отуда достал.

в общем схема не особа надежна, более того в случае WebFarm нужно еще настроить сессию чтобы она была не InProc, а например SQL, тут уже добавится сериализация и сохранение чтение данных из базы, если класть в TempData большие объекты — это может достаточно замедлить обработку.

M>>итого — для работы в "старом" сценарии нужны технические костыли.
M>>в том о чем говорю я все более естесвенно, загрузилась форма(по сути сама она клиент серверное приложение десктопное, ничем не отличается ), она _сама_ провела перичную валидацию, и если ок, послала запрос на сервер.
M>>сервер не делает лишнего, обрабатывает то что прислали и говорит ок/не_ок+детали_что_не_ок. форма получила ответ, адеватно отреагировала, если надо передала управление другой форме( редирект )

O> В общем — да, согласен.
O> Только как же в таком случае делать валидацию?
O> В двух местах писать и поддерживать одну логику валидации иди писать свой генератор клиентского яваскрипта валидации, если хочется на одном jquery без микрософтовского яваскриптовой библиотеки?

не дублировать конечно. генерировать прямо скрипт валидации не нужно. нужно передавать _метаданные_ описсывающие валидационные правила. не обязательно свое, например есть xVal( он правда вроде загнулся) да и MS впринципе прозрело и идет по пути поддержки jquery.

O>>> Признайтесь, Вам нравится писать на javascript'е?
M>>Да, вполне.
O> Мне как-то не удобно дебажить в браузере в маленькой панельке или в маленьком окошке — надо наверно задуматься о втором мониторе

в IE он дебажится в студии.

O>ps Можете подкинуть примерчик какого-нибудь открытого проекта, в котором можно посмотреть как минимумом действий делается обсуждаемый сценарий на asp.net mvc? А то свои велосипеды изобретать слишком затратно, а спросить не у кого )

сходу нет, поищу.

Здравствуйте, mogadanez, Вы писали:

O>> Можно поподробнее, один ключ на что? На один тип модели?
M>вообще один, для каждой сессии пользователя. расчет идет только на то что все происходит очень быстро =) и третий( четвертый,пятый ) запрос не сумеет вклинится между запросом который положил данные в Temp и который их отуда достал.

Да, довольно серьезный архитектурный косяк, который устраняется написанием своих костылей...

M>не дублировать конечно. генерировать прямо скрипт валидации не нужно. нужно передавать _метаданные_ описсывающие валидационные правила. не обязательно свое, например есть xVal( он правда вроде загнулся) да и MS впринципе прозрело и идет по пути поддержки jquery.

Сейчас посмотрел — в студии есть два взаимозаменяемых варианта валидации — скрипты ms и плагин jquery.validation.
http://weblogs.asp.net/scottgu/archive/2010/01/15/asp-net-mvc-2-model-validation.aspx
Буду пробовать.

O>>>> Признайтесь, Вам нравится писать на javascript'е?
M>>>Да, вполне.
O>> Мне как-то не удобно дебажить в браузере в маленькой панельке или в маленьком окошке — надо наверно задуматься о втором мониторе
M>в IE он дебажится в студии.

Да, но в студии ни стили посмотреть, ни DOM проинспектировать...
Да и делается это все равно не юзабельно — ковыряться в половине браузера, которая разделена еще на две части...

O>>ps Можете подкинуть примерчик какого-нибудь открытого проекта, в котором можно посмотреть как минимумом действий делается обсуждаемый сценарий на asp.net mvc? А то свои велосипеды изобретать слишком затратно, а спросить не у кого )
M>сходу нет, поищу.

Может быть удасться выдрать кусочек из своего проекта? Action валидации со скриптами и view'ху.
В этом же нет ничего криминального?
Еще меня интересует ваш опыт — писали ли Вы приложения под нагрузку выше средней (несколько тысяч посетителей в день)?

M> 2.2 — TempData — это конечно пц скажу я вам. во первых, они используют всегда один ключ, и пользователь работающий в нескольких вкладках имеет шанс получить облом. во вторых в случае
а зачем это хранить Tempdata, интересны ведь текущие данные на этой странице.