Судя вот по этой статье, некоторые американские разработчики видели веб-разработку только через призму asp.net. И после выхода asp.net mvc с удивлением для себя заметили, что вокруг мира веб-разработки существует куча других проблем, кроме "как найти подходящий aspnet control для моего сайта/интранет системы". Для человека, всегда работавшего с win-app, трудно понять, что его asp.net приложение не работает, как он хочет, во всех броузерах. Трудно понят, что приложение не хранит состояние между сессиями. Трудно понять почему ему приходится делать работу два раза, clien-side и server-side.
Насчет споров вокруг asp.net mvc. По мне так все эти споры связаны в основном из-за того, что люди приходящие в веб разработку делают это с разных сторон и со своим сложившемся мировозрением на построение приложений.
Кто-то пришел из мира win-application и увидел родной для себя подход в classic asp.net. Кто-то пришел из мира web-application(perl,php,ruby и так далее и тому подобное).
Я так думаю MS не стало бы возиться с asp.net mvc если бы не видело проблем которые пораждает classic asp.net.
PS. Интересно, сколько человек откликнется на этот пост )
Все когда-нибудь заканчивается
Отпуск тоже когда-то кончается и наступают рабочие будни.
ТОЛЬКО АКТИВНЫЙ ВИД ОТДЫХА, в любом его проявлении и виде!
Остальное тут
- Отдыхать в городе - это убийство своего отпуска.
- Отдыхать в другом городе - это покушение на убийство.
- Поход по магазинам во время отпуск - это ограбление своего отпуска.
- Отсыпаться во время отпуска - это убийство своего отпуск.
- Поездка на курорт - это гастроли с совершение тяжких телесных повреждений(отравление, ожирение и обгорание)
ТОЛЬКО АКТИВНЫЙ ВИД ОТДЫХА, в любом его проявлении и виде!
Остальное тут
Использование Http Status Code для обработки ошибок
Довольно не редко требуется обработать ошибку, возникшую на сервере, причем виды ошибок могут быть разными.
Системные ошибок, ошибки пользователя, логические ошибки. Подходы к обработке ошибок, также могут быть разными. Для валидации один поход, для системных другой и так далее.
Перейдем к более близкой мне теме, разработка веб-приложений.
Для любого ответа web-сервер генерирует Status Code. Статусы есть наверное на все случаи жизни сервера и request-а.
Классические:
200 OK - все верно обработано
301 Moved permanently - так называемый редирект
403 Forbidden - нет доступа
404 Not Found - нет такого ресурса
Более экстравагантные:
405 Method Not Allowed
411 Length Required
505 HTTP Version Not Supported
Есть еще один статус, который возникает если во время обработки запроса произошла ошибка в коде "500 Internal Server Error".
Как правило пользователь в браузере видет какую-то жуть несусветную и все исключения или ошибку стараются обработать на сервере и выдать в каком-нибудь удобоваримом виде. После такой обработки тот самый "500" статус теряется и теперь сервер возвращает "200 OK".
Далее на клиенте просто выводится текст ошибки, ну или на что фантазии хватит у разработчика.
Большинство браузеров или js-framework умеют работать с 500 статусом. Например при ajax запросе js-frameworks вываливаются в методы(OnError, onFailure). Броузеры имеют свою страничку для отображения ошибок.
Но, после обработки "500" статус пропадает и "клиент" не узнает об ошибке. Приходиться вводит и обрабатывать дополнительную ситуацию на "клиенте", придумывать форматы для информирования об ошибке и так далее.
Зачем городить огород, если клиент и так настроен на обработку "500" кода. Для того, чтобы клиент все правильно понял достаточно после обработки в HEADER опять поместить "500" ошибку.
Для этого можно записать в респонсе(Asp.Net Mvc):
Response.StatusCode = "500";
Теперь клиент правильно поймет, данные относятся к ошибке. А на сервере надо будет правильно эти данные сформировать. Информированием клиента об ошибке займется протокол HTTP.
Системные ошибок, ошибки пользователя, логические ошибки. Подходы к обработке ошибок, также могут быть разными. Для валидации один поход, для системных другой и так далее.
Перейдем к более близкой мне теме, разработка веб-приложений.
Для любого ответа web-сервер генерирует Status Code. Статусы есть наверное на все случаи жизни сервера и request-а.
Классические:
200 OK - все верно обработано
301 Moved permanently - так называемый редирект
403 Forbidden - нет доступа
404 Not Found - нет такого ресурса
Более экстравагантные:
405 Method Not Allowed
411 Length Required
505 HTTP Version Not Supported
Есть еще один статус, который возникает если во время обработки запроса произошла ошибка в коде "500 Internal Server Error".
Как правило пользователь в браузере видет какую-то жуть несусветную и все исключения или ошибку стараются обработать на сервере и выдать в каком-нибудь удобоваримом виде. После такой обработки тот самый "500" статус теряется и теперь сервер возвращает "200 OK".
Далее на клиенте просто выводится текст ошибки, ну или на что фантазии хватит у разработчика.
Большинство браузеров или js-framework умеют работать с 500 статусом. Например при ajax запросе js-frameworks вываливаются в методы(OnError, onFailure). Броузеры имеют свою страничку для отображения ошибок.
Но, после обработки "500" статус пропадает и "клиент" не узнает об ошибке. Приходиться вводит и обрабатывать дополнительную ситуацию на "клиенте", придумывать форматы для информирования об ошибке и так далее.
Зачем городить огород, если клиент и так настроен на обработку "500" кода. Для того, чтобы клиент все правильно понял достаточно после обработки в HEADER опять поместить "500" ошибку.
Для этого можно записать в респонсе(Asp.Net Mvc):
Response.StatusCode = "500";
Теперь клиент правильно поймет, данные относятся к ошибке. А на сервере надо будет правильно эти данные сформировать. Информированием клиента об ошибке займется протокол HTTP.
Suggest поиск.
Понадобилось мне создать свой suggest поиск и чтобы не изобретать велосипед посетил я ряд проектов, посвященный этой теме.
Вот несколько готовых скриптов и примеров
http://labs.adobe.com/technologies/spry/articles/autosuggest_overview/index.htm
http://www.dynamicajax.com/fr/AJAX_Suggest_Backend-271_290_312_315.html
http://www.brandspankingnew.net/archive/2006/08/ajax_auto-suggest_auto-complete.html
http://alx.vingrad.ru/fwc/ru/examples
http://www.enjoyxstudy.com/javascript/suggest/index.en.html
При создании своего Suggest-а я попробовал разделить процесс получения данных и процесс отрисовки(send-get и draw). Таким образом отрисовка можно спокойно менять.
Так же воспользовался событиями и мой suggest сообщает обо всем что происходит.
Вот несколько готовых скриптов и примеров
http://labs.adobe.com/technologies/spry/articles/autosuggest_overview/index.htm
http://www.dynamicajax.com/fr/AJAX_Suggest_Backend-271_290_312_315.html
http://www.brandspankingnew.net/archive/2006/08/ajax_auto-suggest_auto-complete.html
http://alx.vingrad.ru/fwc/ru/examples
http://www.enjoyxstudy.com/javascript/suggest/index.en.html
При создании своего Suggest-а я попробовал разделить процесс получения данных и процесс отрисовки(send-get и draw). Таким образом отрисовка можно спокойно менять.
Так же воспользовался событиями и мой suggest сообщает обо всем что происходит.
Вот он! AspNet Mvc P4
http://www.codeplex.com/aspnet/Release/ProjectReleases.aspx?ReleaseId=15389
Ждем 5, потом бету, потом альфу, потом релиз ?
Ждем 5, потом бету, потом альфу, потом релиз ?
Вышел Asp.Net Mvc Preview 4
В блоге Scottа Gu появилась запись о выпуске очередного Preview aspnetmvc ворка.
Если раньше выпуск релиза сопровождался изменениями во всех частях ворка, то теперь изменения направлены явно в сторону улучшения и расширения пользовательских функций. Например разработаны готовые фильтры Authorize Filter, HandleError Filter и OutputCache Filter.
Фильтр авторизации использует несколько правил, по роле, по логину.
Фильтр обработки ошибок может по разному реагировать на ошибки, настройка на разные типы exception.
Интересно еще одно нововведение AccountController Class. Это уже реализация целой логики по управлению account-ами.
Как и раньше делаются все усилия чтобы данный продукт легко поддавался тестированию. Этот принцип коснулся и Testing TempData.
Я же со своей стороны жду появления subcontrollers. )
Если раньше выпуск релиза сопровождался изменениями во всех частях ворка, то теперь изменения направлены явно в сторону улучшения и расширения пользовательских функций. Например разработаны готовые фильтры Authorize Filter, HandleError Filter и OutputCache Filter.
Фильтр авторизации использует несколько правил, по роле, по логину.
Фильтр обработки ошибок может по разному реагировать на ошибки, настройка на разные типы exception.
Интересно еще одно нововведение AccountController Class. Это уже реализация целой логики по управлению account-ами.
Как и раньше делаются все усилия чтобы данный продукт легко поддавался тестированию. Этот принцип коснулся и Testing TempData.
With previous ASP.NET MVC Previews you had to mock objects in order to test the TempData collection. With Preview 4 you no longer need to mock or setup anything. You can now add and verify objects within the Controller's TempData collection directly within your unit tests (for example: populate a controller's TempData property before calling its action method, or verify that the action updated the TempData after the action returned). The actual storage semantics of the TempData collection is now encapsulated within a separate TempDataProvider property.И в заключении Скотт пообещал рассказать какие изменения коснутся AJAX в 4 Preview.
Я же со своей стороны жду появления subcontrollers. )
Подписаться на:
Сообщения (Atom)