.NET: Записки программиста о работе в команде, управлении проектами и новых технологиях

Как обойти IIS 7.0 и все-таки вернуть сообщение 404

host.nospam@nospam.developernotes.net (Felix) — Sat, 23 May 2009 16:59:00 PDT

В своем посте "Как правильно создать страницу 404 или один слуга для двух хозяев" я писал, что правильная страница "404" должна не только содержать сообщение, понятное пользователю, но и действительно возвращать 404 код ошибки. Подробно об этом можно почитать в самом сообщении, но если в двух словах, то 404 код ошибки нужен поисковым серверам. Пока поисковики не научились распознавать текст, им нужно явно указывать, что запрошенной страницы нет. Иначе такие ссылки будут долго болтаться в индексе, а сам сервер будет жаловаться, что у нескольких страниц вашего сайта не только одинаковые заголовок и мета-теги, но еще и все содержимое.

Все было хорошо до тех пор, пока я случайно не увидел, что происходит на рабочем сервере. В ответ на ошибочный url браузер отобразил стандартную страницу IIS 7.0 "Page not found".

Полез разбираться. На моем компьютере с Windows Vista и IIS 7.0 все работает отлично - возвращается именно моя страница, прием код возврата - 404. А вот на рабочем сервере с Windows Server 2008 и IIS 7.0 возвращается стандартная страница IIS.

В результате получается, что сначала ASP.NET приложение корректно обрабатывает 404 ошибку и возвращает ответ браузеру. После чего этот ответ перехватывает IIS, видит 404 код и заменяет его на на свое стандартное сообщение. Я не скажу точно, было ли это изначально в Windows Server 2008 или, скажем, появилось вместе с Service Pack 2 - но налицо вот такой неприятный сюрприз. Проявляется он только в IIS Integrated mode, в Classic mode все работает как и раньше. Кстати, это заставляет задуматься о том, что для качественного тестирования желательно иметь среду, аналогичную production server, а не Windows 2000 с IIS 6.0 :)

К счастью, решение нашлось благодаря MS MVP Rick Strah (у него вобще можно найти достаточно много интересных статей по ASP.NET). У Рика были похожие проблемы с кодом 500, который он хотел возвращать клиентскому сервису. В один прекрасный момент, вместо собщения об ошибке и кода 500 сервис стал получать ... правильно, стандартную страницу IIS "Internal server error".

Решить проблему позволило свойство "HttpResponse.TrySkipIisCustomErrors". Оно появилось в ASP.NET 3.5 и как раз позволяет запретить обработку ошибок IIS 7.0 по умолчанию. Что делать, если ваш сайт работает под .NET 2.0? Сам Рик вежливо пишет, что в этом случае "you’re out of luck".

В результате, чтобы сформировать правильный ответ, мы можем создать PageNotFound.aspx с необходимым текстом "Вот незадача, бла-бла-бла..." и примерно таким вот кодом:

protected override void OnLoad(EventArgs e) { base.OnLoad(e); Response.StatusCode = (Int32)HttpStatusCode.NotFound; Response.TrySkipIisCustomErrors = true; // Иначе IIS 7.0 возвращает стандартную 404 страницу }

В последствии, эту страницу можно будет отдавать вызовом

HttpContext ctx = HttpContext.Current; if (ctx == null) throw new NullReferenceException("HttpContext.Current"); ctx.Server.Execute("PageNotFound.aspx", false); ctx.Response.End(); ctx.ApplicationInstance.CompleteRequest();

Вот как-то так. Мне кажется, было бы логичнее, чтобы .NET по умолчанию считал, что TrySkipIisCustomErrors = True, но ... спасибо, что эту проблему можно решить хотя бы так :)

Свой Visual Search провайдер для IE 8 - задача на два помидора

host.nospam@nospam.developernotes.net (Felix) — Fri, 24 Apr 2009 16:45:00 PDT

Visual Search Suggestions - одна из новых возможностей поиска в IE 8.0. Она позволит пользователям искать что-нибудь на вашем сайте, не переходя на его страницы. А если вы добавите к провайдеру favicon, ваш бренд (скорее брендик 16 на 16) всегда будет вместе с пользователем. А главное, она позволит разбавить сухой текст результатов поиска симпатичными картинками, например вот так:

А еще, вы сможете рассказать о своем провайдере, выложив его в галерею расширений IE 8.0. Или выиграть плазменный телевизор, поучавствовав в конкурсе дополнений к IE 8.0, который проводится в рамках конференции ReMIX09.

Между прочим, сейчас там зарегистрировано всего 3 визуальных провайдера, а сам конкурс продлится до 31 мая 2009. Так что если у вас есть что искать, а еще лучше - сайт с верной аудиторией, готовой поддержать его в конкурсе - давайте попробуем?

Сразу предупрежу, что от вас потребуется метод, который будет возвращать найденные по запросу данные. Как он будет выглядеть, зависит от ваших любимых технологий и размера сайта. В примере, показанном выше (сайт с мини играми, который был написан на .NET), это было простое строковое стравнение в LINQ запросе. Кто-то посерьезнее настроит full text search в MS SQL Server, ну а приверженцы PHP и MySQL наверняка тоже смогут подобрать что-нибудь эффективное в своем арсенале.

Если у нас будет такой метод, все остальное - это задача на два помидора¹. Причем, в отличие от web slices, простой вариант решения будет одновременно и хорошим, без всяких оговорок и нюансов.

Итак, в лучших традициях кулинарных программ, для успешного приготовления провайдера нам понадобится:

Сайт с картинками и текстом, которые мы сможем искать - 1 шт
Метод, который примет на вход строку, введенную пользователем в строке поиска и вернет нам немножко текста и картинок - 1 шт.
Модуль, к которому будет обращаться браузер, чтобы получить найденные результаты в xml формате - 1 шт
Еще немножко xml, чтобы описать наш провайдер - 1 шт
И для завершения - щепотка html, чтобы рассказать браузерам, какой чудесный провайдер мы приготовили

Ну что, продукты готовы, вода кипит - приступаем ... Сначала займемся основой нашего блюда - методом поиска, который собственно и будет выполнять всю реальную работу. Как мы и договаривались, его реализация полностью на вас. Абсолютно не важно, как это будет сделано, главное, чтобы он:

Принимал на вход текст, которую пользователь набрал в строке поиска:
Причем учтите, браузер будет обращатся к вашему сайту после каждой введенной буквы, так что искать лучше побыстрее.
Для каждого найденного элемента возвращал:
- Заголовок
- Краткое описание
- URL страницы, на которую мы попадем выбрав этот элемент при поиске
- URL картинки
В принципе, достаточно возвращать только заголовок или url. Но если мы хотим получить красивый результат, нам понадобятся все элементы.

Переходим ко второй части: модулю вашего сайта, к которому будет обращаться браузер, чтобы получить xml с вариантами поиска. Формат вызова вы сможете задать сами, браузер всего лишь добавит к нему несколько параметров, описывающих запрос. Обязательно, нам понадобится только один параметр, в котором и будет передана строка поиска. Запрос может выглядеть примерно так:

http://{домен вашего сайта}/search.aspx?q={searchTerms}

Модуль может быть реализован по разному, например как IHttpModule или WebService. Я предпочел самый простой вариант - обычную html страницу:

<%@ Page Language="C#" CodeBehind="visual.aspx.cs" Inherits="Play2game.VisualProvider" %><?xml version="1.0"?>
<SearchSuggestion xmlns="http://schemas.microsoft.com/Search/2008/suggestions">
  <Query><asp:Literal ID="ltKeyword" runat="server"/></Query>
  <Section title="Варианты Play2Game.ru">
    <asp:Literal ID="ltItems" runat="server"/>
  </Section>
</SearchSuggestion>

Это xml, который нужно будет вернуть браузеру. Он содержит два placeholders (в виде простейших элементов управления ASP.NET Literal control). Вместо первого нам нужно будет вставить строку, которую искал пользователь. Браузер проверит ее и выведет результаты, только если эта строка совпадет со строкой, которую он передал в запросе.

Вместо второго placeholder мы подставим xml с описаниями найденных элементов. Перед тем как перейти к описанию этого xml, обратите внимание еще на две вещи:

Строка <?xml version="1.0"?> находится в одной строке с декларацией страницы не случайно. Если вы напишите ее с новой строки (как сделал это я, так как ненавижу криво отформатированный текст), результирующий xml будет начинатся с символа перевода каретки и не будет распознан браузером (а вы увидите сообщение "ошибка", которое значит "у вас какие-то проблемы, попробуйте как-то изменить ваш код и попробовать снова")
В теге Section мы передали название заголовка, которое будет выведено в самом начале, вместе с серой линией - разделителем. Если бы мы этого не сделали, IE сформировал его сам как "{Название вашего провайдера} вариантов", а это может выглядеть достаточно криво.

Теперь переходим к формату xml с самими результатами (который вставится на место второго placeholder). Он довольно простой:

<Item>
  
  <Text>То, не знаю что</Text>
  
  <Description>Это именно то, что ты искал.</Description>
  
  <Url>/something.html</Url>
  
  <Image source="/something.gif" alt="то, что ты искал" width="45" height="45" />
</Item>
...
<Separator title="Еще один список не знаю чего"/>
<Item>
  ...
</Item>

Тут тоже стоит обратить внимание на два момента. Первый - это размеры картинки. Если их указать - все будет работать отлично. Но если ваши изображения немного отличаются по размеру - это может стать проблемой. Если в обычном html в теге img вы указываете только один размер - ваше изображение будет пропорционально смасштабировано. Тут такой фокус не пройдет - картинки просто перестают показываться (когда я попробовал вообще не указывать размер, изображения нормально выводились при первом запросе после подключения провайдера, а потом все таки исчезли). Так что вам придется придумать, как правильно вычислять размеры.

В этом примере мне повезло - все иконки были одинакового размера 44 на 44. В другой раз было хуже, картинки попались разные и если указать что-то типа 45x45 - масштабировались в квадрат и безжалостно искажались. В конце концов, я добавил метод, который находил физический файл, определял его размеры и корректно проставлял аттрибуты width и height. Вопреки опасениям, работало это достаточно шустро - благодаря второму моменту, о котором мы сейчас поговорим.

Дело в том, что размер списка ограничен - в нем будет выведено не более 10 элементов (поэтому проверить размеры максимум 10 файло было достаточно легко). Эти элементы можно выделять разделителями - тег <Separator title="Еще один список не знаю чего"/> в нашем xml. Однако резделители так же занимают одно из 10 мест. Так что вам нужно будет решить, выводить ли разделители, чтобы красиво сгруппировать найденные элементы или отобразить побольше результатов поиска.

XML с результатами поиска я создавал при помощи простого StringBuilder и вставлял на место placeholder. Если же вы сторонник сложных, но правильных решений, обязательно прочтите пост " Building an IE8 Visual Search Provider for my Twitter Friends" в котором Guy Burstein рассказывает, как правильно создавать такой модуль при помощи WCF REST service и XML serialization.

Почти все готово, осталось две мелочи. Первая - создать xml файл с описанием нашего провайдера:

<?xml version="1.0" encoding="utf-8"?>
<OpenSearchDescription xmlns="http://a9.com/-/spec/opensearch/1.1/" xmlns:ie="http://schemas.microsoft.com/Search/2008/">
  <ShortName>{Название вашего провайдера}</ShortName>
  <Image height="16" width="16" type="image/icon">http://{доменное имя сайта}/favicon.ico</Image>
  <Url type="text/html" template="http://{доменное имя сайта}/search-page.aspx?q={searchTerms}"/>
  <Url type="application/x-suggestions+xml" template="http://{доменное имя сайта}/search.aspx?q={searchTerms}"/>
  <ie:PreviewUrl type="text/html" template="http://suggestions.example.com/search.aspx?q={searchTerms}"/>
</OpenSearchDescription>

На что стоит обратить внимание здесь:

Тег <Url type="text/html" определяет url, который будет вызван, если пользователь просто нажмет ввод в строке поиска, так и не выбрав ни одного из вариантов в предложенном списке. Url вы можете указать произвольный, главное, чтобы он включал placeholder {searchTerms}, вместо которого браузер подставит введенную пользователем строку.
Если на вашем сайте уже реализован поиск - направьте этот url туда. Если нет - доверьте это вашему любимому поисковому серверу, например вот так:
<Url type="text/html" template="http://www.google.com/search?q={searchTerms}"/>
Тег <Url type="application/x-suggestions+xml" определяет url нашего модуля, который должен вернуть xml с результатами. Условия те же: произвольный url с обязательным placeholder {searchTerms}, вместо которого браузер подставит строку для поиска. Кроме этого, в можете использовать еще несколько placeholders и тогда браузер передаст вам немного дополнительной полезной информации. Так, например, запрос вида:
<Url type="text/html" template="http://www.google.com/search?q={searchTerms}&language={Language}"/>
позволит вам узнать язык, установленный у пользователя (user's system's locale). А при помощи запроса:
<Url type="text/html" template="http://www.google.com/search?q={searchTerms}&maxwidth={maxWidth}&rowheight={rowHeight}&sectionHeight={sectionHeight}"/>
вы сможете получить точные размеры выпадающего окошка и лучше сформировать xml с результатами поиска. Подробное описание дополнительных параметров вы сможете найти в документации, ссылка на которую приведена в конце статьи.
Все установленные поисковые провайдеры автоматически добавляются и как IE Accelerators (ускорители поиска, еще одна новинка IE 8.0). Поэтому, если пользователь выделит какой-то текст на странице сайта и вызовет список ускорителей - ваш поисковый провайдер тоже будет в этом списке. Строка:
<ie:PreviewUrl type="text/html" template="http://suggestions.example.com/search.aspx?q={searchTerms}"/>
позволяет указать url вашего сайта, который вернет html для отображения в preview окне ускорителя. Подробнее об ускорителях поиска вы сможете узнать в статье "OpenService Accelerators Developer Guide" из документации MSDN.

Последний штрих художника - добавим html тег с описанием провайдера в head нашего сайта. Выглядит он вот так:

Найдя его на нашем сайте, IE станет оранжевым от нетерпения и предложит добавить наш провайдер к уже зарегистрированным в нем поисковым провайдерам. Обратите внимание, значение аттрибута "Title" должно точно совпадать с аналогичным названием в теге "ShortName" описания провайдера. Если эти строки будут различатся, браузер не поверит, что уже добавил этот провайдер и будет предлагать добавить его снова.

Ну что, прошу к столу, вскипело!

А напоследок еще один совет, который поможет сделать приготовление провайдера более приятным. Браузер кеширует полученный xml, так что постоянно меняйте вводимые во время тестирования слова. Какое-то время я безуспешно пытался понять под отладчиком, почему же не вызывается мой модуль, когда я набираю классическое "sdfsdf" (еще варианты "йцукен" или "qwerty"). А если вам захочется разобраться во всех деталях - загляните в главную поваренную книгу Microsoft: Search Provider Extensibility in Internet Explorer и XML Search Suggestions Format Specification, а так же прочтите статью Себастьяна Циммермана (основного разработчика функции Visual Search) Hello, World или начинаем работать с IE8 Visual Search.

Приятной вам готовки и победы в конкурсе!

¹ В XP время может измеряться в произвольных единицах, например баллах или Мишках Гамми. Мартин Фаулер как-то рассказывал о Франческо Чирилло, который купил и принес на работу тридцатиминутный кухонный таймер в форме помидора. С тех пор в команде появилось выражение «задачка на шесть помидоров».

robots.txt - небольшое продолжение

host.nospam@nospam.developernotes.net (Felix) — Thu, 02 Apr 2009 14:44:00 PDT

Я читал, что поисковый сервер перебирает все правила в robots.txt и останавливается на первом подходящем. Поэтому, я наивно полагал, что если разместить блок "User-agent: *" в начале файла, его правила будут использоваться в любом случае. То есть, мой robots.txt выглядел так:

# Общие правила для всех поисковиков: служебные страницы для логина и пр.
User-agent: *
Disallow: /login
Disallow: /signup
...

# Указание на файл с картой сайта
Sitemap: http://{доменное имя}/sitemap.xml

# Дополнительные правила для Google (используя расширенный синтаксис)
User-agent: Googlebot
Disallow: /*/edit$

# То же самое для Yandex
User-agent: Yandex
Disallow: /*/edit$

Однако, случайно я обнаружил, что страница "/login" вполне доступна для индексирования (проверял в инструментах веб-мастера Google и Yandex). Оказалось, что если в robots.txt есть секция для конкретного поискового севера (например, "User-agent: Yandex"), этот сервер вообще не обращает внимания на остальные секции, в том числе и на "User-agent: *". Единственное правило, которое они обнаруживают в любом месте, это "Sitemap:" - он доступен всем и везде не смотря на строки "User-agent:". В результате мне пришлось скопировать общие правила во все остальные разделы, вот так:

# Общие правила для всех поисковиков: служебные строницы для логина и пр.
User-agent: *
Disallow: /login
Disallow: /signup
...

# Указание на файл с картой сайта
Sitemap: http://fannet.org/sitemap_index.xml

# Правила для Google (используя расширенный синтаксис)
User-agent: Googlebot
Disallow: /login
Disallow: /signup
Disallow: /*/edit$

# То же самое для Yandex
User-agent: Yandex
Disallow: /login
Disallow: /signup
Disallow: /*/edit$

Такое поведение относится как к Google, так и к Yandex. Имейте это ввиду, когда будете составлять robots.txt для ваших сайтов.

Robots.txt или Кое что о роботах

host.nospam@nospam.developernotes.net (Felix) — Sat, 14 Mar 2009 15:51:00 PDT

Файлы robots.txt просты как угол дома и используются со времен, когда 3" дискеты считались прорывом в технологии :) Именно по этому я думал, что в них нечего и разбираться. Так что обходился копи-пастом какого-то образца, который переходил у меня из проекта в проект уже несколько лет.

Но вот однажды, затеял я эксперимент с индексацией сайта. Выложил его в инет, добавил в "Инструменты для веб-мастеров" Google и ... увидел сообщение "Страницы вашего сайта недоступны для Google из-за огранчений в robots.txt". А файл-то был простейший, создавался он ради одной строчки "Sitemap: http://доменное имя/sitemap.xml", чтобы лишний раз указать поисковикам где искать карту сайта.

Между прочим, robots.txt кешируется Google примерно на день, так что после исправления пришлось ждать более суток. Вобщем я вздохнул и полез разбираться с темой.

Robots.txt был придуман в далеком 1994 году и был предназначен для того, чтобы указать поисковикам, что не следует индексировать на вашем сайте.

Его формат действительно очень простой: записи, разделенные пустыми строками. Каждая запись состоит из директив, к каким поисковикам она относится (одна или несколько строк User-agent:) и операторов Disallow: (один или несколько), которые указывают, что именно запрещается индексировать. Если в файле встречается символ "#", то все остальное до конца строки считается комментарием.

Например:

# Самый простой вариант, разрешает индексировать все (или, точнее, запрещает ничего :)
User-agent: *
Disallow:

# Всем роботам запрещена индексация файлов в каталоге "/tmp"
# Кроме того, роботам Slurp (Yahoo) и MSNbot (MSN) запрещена индексация файлов в каталоге "/map"
User-agent: *
Disallow: /tmp/

User-Agent: Slurp
User-agent: MSNbot
Disallow: /map/

Проблема этого формата в том, что с 1994 года он официально не менялся. А вот сложность сайтов и иерархии их urls менялась да еще как. Если эти правила устраивали сайты, состоящие из нескольких десятков статических страниц, то для ~~доров, говносай~~ современных сайтов с динамическим контентом этого явно не хватает.

Вы же не думали, что в стандартных правилах можно использовать хоть какие-то шаблоны? Формат "Disallow:" очень прост: запрещается индексация любых urls, которые начинаются с указанной строки.

То есть, "Disallow: /map/" запрещает все файлы в каталоге "/map", но не запрещает "/map.html". А вот "Disallow: /map" запрещает и то и другое.

Проблема часто возникает, если вы используете url rewriting. Например, у вас есть сайт со описаниями товаров. Url страницы с описанием:

/{категория}/{название товара}-{id товара}

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

И есть страница с отзывами покупателей, ее url:

/{категория}/{название товара}-{id товара}/comments

А так же есть страница, на которой пользователи могут добавлять новые отзывы, ее url:

/{категория}/{название товара}-{id товара}/comments/add

Эта страница доступна только залогиненным пользователям, так что нужно запретить ее индексацию. Без шаблонов или регулярных выражений тут просто не обойдешься.

Тут вы могли подумать "А зачем для служебных страниц использовать friendly urls? Создай себе одну страницу и запрети ее в robots.txt". Да это выход, но не всегда. Будет удобно, если страница добавления отзыва будет выглядеть так же, как и остальные страницы с описанием, в том числе с той же шапкой и боковыми модулями. Так как модули независимы, они могут рассчитывать на url определенного формата (например на то, что он включает в себя категорию товара). Так что проще использовать такой же формат url, чем добавлять везде проверки "если категория есть в url - взять ее оттуда, иначе - определить по id товара".

Крупные поисковые сервисы пошли привычным путем - стали вводить свои уникальные расширения. Так, Yahoo добавило возможность использования символов * и $. Символ * обозначает любую (в том числе и пустую) последовательность символов, а $ - конец строки. То есть, в нашей ситуации с товарами, мы сможем запретить индексацию страниц с добавлением при помощи оператора:

Disallow: /*/comments/add$

Правда, этот пример не поможет, если у вас используются еще и параметры query string, тогда нужно писать так:

Disallow: /*/comments/add$
Disallow: /*/comments/add?

Обратите внимание, что по умолчанию ко всем правилам приписывается *, поэтому нам можно не писать:

Disallow: /*/comments/add?*

Основные моменты, на которые стоит обратить внимание:

В стандарте robots.txt (тут расположена последняя версия стандарта robots .txt) существуют только операторы "User-agent:", "Disallow:" и комментарии. Все. Шаблоны не поддерживаются.
Существуют расширения, которые поддерживаются основными поисковыми серверами. Это:
1. Шаблоны * и $. Признаются как минимум Google, Yandex, Yahoo! и MSN.
2. Sitemap - для указания url с картой сайта. Эта строка обнаруживается поисковыми серверами вне зависимости от операторов "User-agent:". Признается как минимум Google, Yandex, Yahoo! и MSN.
3. Allow - синтаксис аналогичен Disallow, смысл - прямо противоположный. То есть, если среди сотен документов нам нужно запретить почти все, то удобнее разрешить оставшиеся документы, а следующим оператором запретить все остальное:
  User-agent: *
  Allow: /post/page1
  Allow: /post/page2
  Allow: /post/page3
  Disallow: /
  Признается как минимум Google, Yandex, Yahoo! и MSN.
У каждого поискового сервера могут существовать свои полезные расширения.
Так, например, Yandex поддерживает операторы Host (позволяет указать основной сайт среди нескольких зеркал), Crawl-delay (позволяет снизить интенсивность обращений поисковика к страницам сайта, если он и так загружен) и Clean-param (позволяет указать, какие параметры query string не влияют на уникальность страницы; тогда Yandex не будет загружать все urls с различными вариантами этих параметров).

И еще несколько полезных советов ...

Не старайтесь экспериментировать со структурой robots.txt, будьте проще :) Безобидное, на ваш взгляд, изменение строки или слова может привести к тому, что какой-то поисковик перестанет индексировать ваши страницы.

Лучше начинать комментарии с новой строки (хотя стандарт допускает использование их в конце оператора), использовать большие буквы точно как в примерах (Sitemap, а не SITEMAP), четко указывать, к какому серверу относятся конкретные операторы.

Знаете, из-за чего Google решил, что в robots.txt я блокирую весь сайт? Файл состоял всего из двух строчек:

User-agent: *
Sitemap: http://{доменное имя}/sitemap.xml

Считается, что оператор Disallow должен присутствовать в каждой записи. Тут он был пропущен и Google воспринял его как "Disallow: /". Возможно это был какой-то сбой, так как на странице "Анализ robots.txt" в инструментах для веб-мастеров, Google сообщил, что все ок. Но стоит ли рисковать, если от этого зависит индексация ваших страниц.

Для крупных поисковых серверов, вы можете проверить какую-либо из ваших конструкций в инструментах веб-мастера.
Так, для Google это страница "Панель инструментов > Инструменты > Анализ Robots.txt" (url не указываю, так как он зависит от залогиненного пользователя \ адреса вашего веб-сайта).
Robots.txt (кстати, называть его так - тоже ошибка, файл нужно создавать имено с маленькой буквы :) для Yandex можно проверить на странице Анализ robots.txt.

Внимательно изучите описание robots.txt и его расширений для разных поисковых серверов:
robots.txt для Google
robots.txt для Yandex.ru
Yahoo!'s Web Crawler - описание поискового бота Yahoo!, в том числе описан и формат robots.txt для Slurp (поисковый бот Yahoo!)
Все о файле robots.txt по-русски (отсюда я ~~спи~~ позаимствовал картинку с роботом, надеюсь ссылка на их сайт компенсирует моральные потери :)

И да будут поисковые сервера к вам благосклонны :)

Web Slices для IE 8 или "легко ли сластить писиками"

host.nospam@nospam.developernotes.net (Felix) — Sat, 14 Feb 2009 14:31:00 PST

Если вы слушали доклады или читали статьи о новинках IE 8, то должны помнить, что добвить web slices (веб-фрагменты) к своему сайту проще простого. Легкий взмах руки (добавление 2-3 аттрибутов в html) - и вы смело можете утверждать, что ваш сайт по полной использует возможности новой версии браузера!

Но так ли все просто на самом деле? Конечно, в наше время верить в чудеса стало легче. Кто-то еще помнит, сколько усилий и времени нужно было потратить, чтобы заставить общаться клиентскую и серверную части кода по DCOM? Чувствуете разницу, реализуя все то же сейчас на WPF? (кстати, намного больше усилий приходилось тратить не на реализацию, а на поддержку этого рершения в локальных сетях заказчиков; в десяти случаях все нормально, в одиннадцатом - нет; и сеть такая же, и руки админ мыл - а не работает. Ладно, это так, лирика :)

Знаете, в программировании, да и в любой другой высокотехнологичной среде, вместо ответов "да" и "нет" практически всегда звучит "да, но ..." и "нет, хотя ...". И это правильно, ведь для того, чтобы правильно задать вопрос, нужно знать большую часть ответа. Вот и сейчас, можно смело сказать, "да, легко, но ...".

Ну что, посмотрим, что скрывается за этим многоточием?

Для наглядности возьмем пример, на котором я разбирался с web slices сам: модуль, выводящий последние результаты футбольных матчей. Для web slices это практически идеальный кандидат - часть страницы с постоянно обновляющейся информацией, которая интересна многим пользователям.

В лучших традициях инкапсуляции сам модуль выглядит у нас так:

<common:LiveResults ID="lr" runat="server"/>

Итак ...

Web slices - взгляд первый

Легкий взмах руки:

Выделяем нужную нам область тегом div, отмечаем его классом "hslice" и придумываем какой-нибудь id (это обязательное условие для web slices, не важно какой, но id нужен)
Внутрь div-а добавляем тег, помеченный классом "entry-title". Он нужен для того, чтобы IE мог определить название нашего веб-фрагмента. Устанавливаем ему стиль "display:none", чтобы сделать невидимым для пользователя.

Кончно, можно прекрасно использовать и тег с заголовком внутри нашего модуля. Я вынес заголовок, чтобы полностью изолировать логику web slice от user control и оставить ему только отрисовку результатов. А будут они отображаться на странице или как web slices - не user control-ного ума дело.

Получаем вот что:

<div id="liveRes" class="hslice">
<span class="entry-title" style="display:none">Online-результаты</span>
<common:LiveResults ID="lr" runat="server"/>
</div>

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

Часть ответа со словом "да" мы честно отработали. Теперь посмотрим, что у нас означает "но".

Web slices - взгляд второй

Изучаем описание web slices в MSDN и сразу расстраиваемся от неэффективности нашего решения. Всякий раз, когда браузеру нужно обновить содержимое web slice, он запрашивает нашу страницу целиком и выбирает из нее нужные данные. Логично, а откуда он их еще возьмет? И если на ваш сайт заходит пара сотен человек в день - на это можно смело не обращать внимание. А вот для тысяч посещений - это уже расточительство, по крайней мере, если вместе с web slices на странице выводится и другая информация (а значит и идут обращения к базе, выполняется серверный код и т.д.). Кроме того, размер страницы может быть очень большой и все это ~~барахло~~ содержимое браузеру приходится перетаскивать с сервера, чтобы просто понять, что данные изменились или отрисовать ваш фрагмент в выпадающем окне.

Для решения этой проблемы существует такая штука как "Alternative Update Source". Это указание браузеру запрашивать для обновления другой url, а не тот, на котором был найден web slice. То есть, мы добавляем к нашему фрагменту еще одну строку:

которая так же невидима для пользователя. LiveResultsUpdate.aspx - это страница, которая отдает только содержимое web slice, ее и будет запрашивать браузер для обновления.

Разбираемся дальше. Так как web slices являются частью "Windows RSS Platform", то по сути браузер воспринимает указанный url как RSS поток. То, что там расположен наш html с разметкой - удобная абстракция, которая позволяет программистам не заботиться о формировании XML с обновлениями. На самом деле страница LiveResultsUpdate.aspx может возвращать XML примерно такого вида:

<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:cf="http://www.microsoft.com/schemas/rss/core/2005">
  <channel xmlns:cfi="http://www.microsoft.com/schemas/rss/core/2005/internal" cfi:lastdownloaderror="None">
    <title cf:type="text">Online-рузультаты футбольных матчей</title>
    <link>http://fannet.org/WebSlices/LiveResultsUpdate.aspx</link>
    <ttl>15</ttl>
    <item>
      <title xmlns:cf="http://www.microsoft.com/schemas/rss/core/2005" cf:type="text">Online-результаты</title>
      <link>http://fannet.org/live</link>
      <guid isPermaLink="false">c465d0e169db3b4eb0db5e1898224134</guid>
      <description>
        Тут расположено содержимое нашего web slice.
      </description>
    </item>
  </channel>
</rss>

И это будет лучше, так как в XML мы сможем явно указать различные параметры и избавим браузер от необходимости преобразования html в XML.

Из тегов канала (channel) нас интересует только "ttl", указывающий частоту обновления нашего фрагмента в минутах. 15 минут - минимальная частота, по умолчанию она равна 1 дню.

Значения остальных тегов:

title - название web slice, будет отображаться на кнопке панели "Избранное"
link - url, на который мы перейдем, если кликнем на самую левую кнопку внизу окошка с web slice (вторая кнопка обновляет сдержимое самого окошка)
guid - значение, на основании которого браузер будет определять, изменилось ли содержимое web slice. Если оно обновилось, текст на кнопке с web slice должен стать жирным (хотя это можно отключить в настройках вашего браузера)
description - собственно содержимое web slice

Продолжаем разбираться с тонкостями. Кроме "Alternative Update Source" существует еще такая вещь как "Alternative Display Source". По сути, это еще один url вашего сайта. Если вы его зададите, в окошке с web slice будет отображаться содержимое именно этой страницы.

Перед тем как объяснить, зачем он нужен, хочу уточнить, что "alternative update source" и "alternative display source" не зависят друг от друга. Вы можете использовать только "alternative update source" или только "alternative display source" или оба вместе.

Так вот, "alternative display source" может оказаться полезным сразу по нескольким причинам:

Во-первых, по нажатию кнопки на панели web slice отобразиться в маленьком окне. Оно маленькое (по умолчанию 320 x 240), поэтому вы можете захотеть выводить содержимое web slice не так, как он выводиться на страницах вашего сайта. Например, убрать большой заголовок, сделать поменьше шрифт, убрать отступы. Поэтому "alternative display source" нужно использовать, когда вы хотите формировать html для web slice, заточенный для отображения в маленьком окошке.
Во-вторых, если мы используем "alternative display source", то в preview окне выводятся текущие, а не закешированные данные. Иначе там будет отображаться закешированная информация, которая обновляется с указаной вами периодичностью. И, в любом случае, этот период не может быть меньше 15 минут. Иногда это очень неудобно. Возьмем наш пример с результатами матчей. Данные на сайте обновляются примерно раз в две минуты. Если вы следите за ходом матча, то узнавать новости раз в 15 минут не совсем то, что вы хотели, верно? К сожалению, с ограниченим в 15 минут мы ничего не сделаем, но, по крайней мере, у нас будет возможность просматривать текущие результаты в preview окне, не открывая всю страницу.
Есть еще одна полезность "alternative display source". Мы помним, что содержимое web slice (неважно, взят он со страницы или формируется при помощи "alternative update source") воспринимается как RSS. Соответственно на содержимое такого web slice накладываются ограничения: в нем не поддерживаются скрипты, ActiveX компоненты, формы и кнопки с post-запросами. А вот в html от "alternative display source" все это использоваnm можно. Конечно, какие-то ограничния есть и там, но они мягче. Например, нельзя использовать всплывающие диалоги и не поддерживается инсталляция ActiveX (если он уже проставлен в браузере, использовать его можно).

Есть еще один момент, на который стоит обратить внимание. Если вы одновременно используете "alternative update source" и "alternative display source", то содержимое web slice, которое передается в "alternative update source" становиться ненужным. Для определения, обновились ли данные, лучше использовать guid в "alternative update source", а отображаться в окошке все равно будет html, который запрашивается у "alternative display source".

Таким образом, если вы хотите реализовать web slice совсем-совсем оптимально, лучше всего поступить так:

Выделяем участок страницы, который мы хотим отображать как web slice. Указываем там заголовок и ссылку на "alternative update source":
<div id="liveRes" class="hslice">
  <div style="display:none">
    <span class="entry-title">Online-результаты</span>
    <a rel="feedurl" href="http://developernotes.net/WebSlices/LiveResultsUpdate.aspx"></a>
  </div>
  <common:LiveResults ID="lr" runat="server"/>
</div>
Страница LiveResultsUpdate.aspx формирует RSS без самого контента, но с ссылкой на "alternative display source":
<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:cf="http://www.microsoft.com/schemas/rss/core/2005">
  <channel xmlns:cfi="http://www.microsoft.com/schemas/rss/core/2005/internal" cfi:lastdownloaderror="None">
    <title cf:type="text">Online-рузультаты футбольных матчей</title>
    <link>http://fannet.org/WebSlices/LiveResultsUpdate.aspx</link>
    <ttl>15</ttl>
    <item>
      <title xmlns:cf="http://www.microsoft.com/schemas/rss/core/2005" cf:type="text">Online-результаты</title>
      <link>http://fannet.org/live</link>
      <guid isPermaLink="false">c465d0e169db3b4eb0db5e1898224134</guid>
      <atom:link xmlns:atom="http://www.w3.org/2005/Atom" href="http://fannet.org/WebSlices/LiveResultsDisplay.aspx" rel="entry-content"/>
      <atom:link xmlns:atom="http://www.w3.org/2005/Atom" href="http://fannet.org/WebSlices/LiveResultsUpdate.aspx" rel="alternate"/>
    </item>
  </channel>
</rss>
Страница LiveResultsDisplay.aspx отдает html, оптимизированный для отображения в preview окне для web slice.

В результате, для автоматического обновления браузер будет запрашивать отдельный RSS, содержащий только guid и параметры web slice, а при нажатии кнопки в "Избранном" будет отображаться актуальный (незакешированный) html, который специально оптимизирован для отображения в маленьком окне.

Уф, мы почти добрались до конца, осталась пара изюминок, которые позволят довести ваш web slice до безумного совершенства :)

Web slices - взгляд третий

Scrolling

В документации по web slices рекомендуется создавать их таким образом, чтобы они нормально отображались в окошке размером 320 на 240 px. Именно в таком окне выведется web slice, когда пользователь нажмет кнопку на панели "Избранное" первый раз. Размер окна не подстраивается под размер web slice. Пользователь может растянуть его сам до определенных размеров, но сами вы никак не можете этим управлять.

Мало того, это preview окно имеет одно неприятное свойство - если html в нем не помещаеться, вертикальной прокрутки (scrolling) в нем все равно не будет. Я так и не понял, объясняется ли это какими-то причинами или является просто ошибкой, но - прокрутки там нет. Т.е. если один и тот же html вы отобразите просто в IE - прокрутка есть, а в preview окне - нет.

Конечно, некоторые web slices имеют фиксированный размер, так что такое ограничение для них не проблема. Хороший пример - лоты на eBay. Фрагмент с описанием лота легко отобразить в небольшой зоне, которая прекрасно выводиться в preview.

Однако часто web slices представляют собой списки: последние новости, анонсы, музыка, товары, да мало ли. Иногда можно обойтись и тут - например отображать последние три анонса, выводя не более 300 символов текста для каждого + картинка фиксированного размера.

Но есть случаи, когда это не удобно. Например, нам нужно выводить весь текст, длину которого заранее мы не знаем. Или мы хотим вывести все элементы списка, а их количество постоянно меняется. Вот попробуйте зайти на страницу http://valuta.online.ua и добавить web slice с курсами валют. А теперь откройте окошко. Что, тоже крутите скроллер на мыши и ничего не получается, да? Мало того, если растянуть окно по максимуму, все строки все равно не влезут (ну разве что у вас о-очень большой дисплей).

Scrolling был нужен и для результатов матчей. Дело в том, что их количество постоянно меняется. Сегодня играют 10 - 15 игр, а завтра - одну или вообще ни одной. Выводить первых три не хотелось - даже основных матчей бывает много и выбирать из них только несколько - значить превратить web slice в простой баннер, а-ля "а вот у нас есть результаты матчей, заходите к нам!". Поэтому пришлось немного поэкспериментировать со стилями.

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

Итак, html, который будет возвращаться в preview окне панели "Избранное", может выглядеть так:

<html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <title>Online-рузультаты футбольных матчей</title>
    <style type="text/css">
      html { height: 100% }
      body { padding: 0px; margin: 0px; height: 100% !important; overflow: hidden; }
      #outer { overflow-x: hidden; overflow-y: auto; height: 100% }
      #inner { padding: 10px; }
    </style>
  </head>
  <body>
    <div id="outer">
      <div id="inner">
         
      </div>
    </div>
  </body>
</html>

В результате наш html выводится с padding 10px от границ окна и при необходимости в нем появляется вертикальный скроллинг. Аттрибуты "overflow-x" и "overflow-y" уникальны для IE, но и web slices уникальны только для него же, так что проблемы не возникнет.

Ссылки в окне preivew

Если вы кликнете по какой-то ссылке в окне preivew, новая страница отобразиться там же. Вряд ли это то, что вы хотели, так как остальные страницы вашего сайта не предназначены для отображения в маленьком окошке. Для того, чтобы страница открылась в нормальном окне браузера, вам нужно добавить аттрибут target="_blank" ко всем вашим ссылкам (это, кстати, еще один повод использовать "alternative display source". Когда вы отображаете web slice на странице сайта такое поведение вам ни к чему).

Favorite icon

Возможно это был какой-то локальный сбой, но! Добавляю web slice, он добавляется, но на кнопке выводиться картинка по умолчанию, а не favirite icon сайта. Мелочь - а неприятно. Причем, если web slice задан только при помощи html аттрибутов, без "alternative update source" - все ок, иконка есть. А если с "update source" - нет.

Прошелся по сайтам с web slices, у кого-то добавляется, у кого-то нет, но разницы понять не смог. После нескольких часов экспериментов получилось - для этого нужно было поместить favorite icon в корень сайта и назвать его стандартно "favicon.ico". В принципе, так и рекомендуется делать, но мне было приятнее собирать все изображения в папке "img", так что favicon жил у меня там. После этого иконка стала нормально отбражаться.

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

Уф, вроде бы все. Естественно, любое описание не сможет заменить документации MSDN. И удачи вам в разработке!

P.S.

На сайте IE 8 есть галерея расширений, в том числе и web slices. А в RC1 на панели IE появилась кнопка "Get more Add-ons". Многие пользователи, проставившие IE (особенно после выхода релиза), заглянут на эту страницу, так что если вы добавите ваш web slice в галерею - это даст дополнительный трафик на ваш сайт.

Браузеры, кнопка "Back" и кеширование страниц

host.nospam@nospam.developernotes.net (Felix) — Fri, 23 Jan 2009 09:10:00 PST

Это - браузеры. Они отображают наши станицы.
А это - кеш браузера. Он старается, чтобы наши страницы отображались быстрее.
А это - AJAX. Он тоже старается, чтобы наши страницы отображались быстрее.
Но иногда, приходится стараться, чтобы они так не старались. Об одном таком случае и пойдет речь.

Итак, представте, что на вашем сайте есть страница, которая сама периодически обновляет список с online-информацией. Да через тот же AJAX. Чтобы представлять было проще, возьмем конкретный пример - текущие результаты футбольных матчей, которые обновляются примерно раз в две минуты. Болельщик открывает страницу - и на ней всегда актуальная информация. Теперь, он уходит на другую страницу, скажем, посмотреть описание какого-то матча. А потом ему хочется вернуться и он нажимает кнопку "Back". И видит, что последний раз результаты матчей обновлялись в момент, когда он уходил с этой страницы.

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

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

Первым делом, я решил запретить кеширование страницы. Результат был несколько странным - под IE все работало нормально, под FF - ничего не изменилось.

Ну вот, опять приходится читать документацию, вздохнул я и начал читать. В результате оказалось, что разработчики разных браузеров оптимизируют логику работы "Back" каждый по своему:

IE 8.x\7.x обращает внимание на настройки кеширования и берет страницу из кеша только если кеширование разрешено
FF 3.x просто берет страницу из кеша, даже если кешировать ее нельзя
Opera 9.x тоже берет страницу из кеша

Причем каждая команда как-то объясняет свой вариант и естественно считает его самым лучшим.

Порывшись в сети, я нашел простое решение:

// Refrech page after back button
function reloadIfBack()
{
var e = document.getElementById("refreshed");
if (e.value=="no")
{ e.value="yes"; }
else
{ e.value="no"; location.reload(); }
}
$(document).ready(reloadIfBack);

<input type="hidden" id="refreshed" value="no" />

Тут есть чуть jQuery, но даже, если вы с ней не знакомы, код должен быть понятен:

Добавляем на страницу hidden поле, в котором сохранено состояние страницы "не обновлялась"
На событие "страница загружена" вешаем метод "reloadIfBack"
Этот метод проверяет, значение hidden поля. Если значение "no" - станица взята с сервера, тогда просто меняем его на "yes". Если "yes" - значит страница взята из кеша, сбрасываем поле и перезагружаем страницу

После этого под IE и FF все заработало, а вот под Opera осталось как и прежде. Оказалось, что у Opera система кеширования сильно переработана и отличается от IE и FF. Они очень гордятся тем, что страницы после "Back" открываются почти мгновенно, в минусах - идеи как обновить страницу я так и не нашел. Вернее я встретил одно описание, но мне настолько не понравилась его суть (это решение выбрасывало исключения под IE и FF, так что его приходилось брать в мертвый catch {}), что даже не стал ее проверять.

Потратив еще немного времени, я решил оставить все как есть, успокоив себя тем, что Opera распространена не так сильно, да и проблема не большая - все равно страница вскоре обновится. Но если у вас будут идеи, как заставить работать и Opera - пишите, буду рад это обсудить.

Видео с Дней разработчиков 2008 в Украине

host.nospam@nospam.developernotes.net (Felix) — Wed, 24 Dec 2008 13:09:00 PST

Сегодня Сергей Байдачный начал выкладывать видео докладов с Дней разработчиков 2008 в Украине.

В том числе и мой - Введение в ADO.NET Entity Framework (я писал о нем в одном из предыдущих сообщений "Мой доклад на Developer Days 2008").

Жалко, что в ролики не вошли вопросы и ответы - обычно это самая живая часть докладов. А еще, пересматривая видео, я понял, почему доклад прошел минут за 40, хотя дома, когда я рассказывал его своей стенке, на это уходил положенный час. Если бы мой темп немного замедлить - получилось бы и спокойнее и понятнее. Но тем не менее, если выставить громкость на полную - смотеть его вполне можно :)

Приятного!

Как правильно создать страницу 404 или один слуга для двух хозяев

host.nospam@nospam.developernotes.net (Felix) — Sat, 20 Dec 2008 09:22:00 PST

"А что тут сложного?" удивитесь вы. А потом, подумав "вряд ли он ответит 'ничего' и этим закончит статью", спросите - "а в чем подвох?".

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

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

Разработчики сайтов конечно понимают, что так поступать нельзя. Если это не ваш постоянный посетитель - после такого ответа вы его потеряли. Поэтому на сайте создается специальная страница, которая выводится, когда никто не знает что делать с этом странным адресом. Она имеет такой же внешний вид как и остальные страницы сайта и должна сказать посетителю "Все замечательно и под контролем! Да, вот этой информации у нас нет, но вы можете поискать здесь, или перейти вот сюда".

Вот так это, например, выглядит на сайте "сами знаете кого":

А теперь, посмотрим чуть дальше. Да, с пользователем мы разобрались. А вот что будет с поисковыми серверами?

Небольшой следственный эксперимент. Создаем пустой ASP.NET проект и добавляем к нему стандартную обработку страниц, которых нет. Это делается очень просто:

Создается новая страница, допустим PageNotFound.aspx, на которой вы отображаете все что хотите сказать пользователю.
Вносим изменение в web.config:
<customErrors mode="On" defaultRedirect="GenericErrorPage.htm">
<error statusCode="404" redirect="PageNotFound.aspx" />
</customErrors>

Пробуем. Открываем наш сайт, запршиваем какую-нибудь "bla-bla-bla.aspx" - вуаля, мы видим нашу, только что созданную страницу. Все работает?

А теперь заглянем чуть глубже. С красивого уровня графики нырнем сразу на два уровня ниже -на уровень HTTP протокола. Открываем ваш любимый "сниффер" (у меня это - HttpWatcher) и еще раз запрашиваем "bla-bla-bla.aspx". Что мы видим:

То есть, кода 404 у нас вообще нет, вместо него есть редирект 302 ("ресурс был временно перемещен") на нашу PageNotFound.aspx.

А теперь представьте, что в кеше поисковика есть какое-то количество ваших несуществующих urls. Причины могут быть разные:

Самая распространенная - для SEO оптимизации вы изменили структуру url. Конечно, вы позаботились о перенаправлении старых адресов, но что-то просто могли упустить или немного запутались в большом количестве правил.
Еще вариант - изменилась физическая структура сайта и часть страниц действительно исчезла. У меня так случилось при смене движка этого блога. О перенаправлении статей я позаботился, но часть страниц, которые создавал старый движок, пропала, а подходящего аналога в новой версии не было. Тупо перебрасывать эти запросы на главную страницу я не хотел, чтобы не смущать поисковик.
У вас большой сайт с сотнями тысяч страниц и сложной структурой. Этот сайт периодически меняется, так что поисковики постоянно накапливают какие-то, уже несуществующие адреса. Их может быть совсем немного, но при умножении на размер сайта и продолжительность его жизни - величина получится вполне приличная.

В результате, с точки зрения поисковика все эти страницы продолжают существовать и ведут на одну и ту же страницу вашего сайта. Если вы пользуетесь Google \ Yandex Web Master, то увидите их в списках с ошибками. Ничего серьезного скорее всего не произойдет, но:

Они могут оставаться в кеше поисковика достаточно долго, так как 404 кода ("страница не существует") ему никто не отсылал.
Существует мнение (и мне оно кажется вполне логичным), что поисковики больше любят (читай, чаще индексируют, больше доверяют и т.д.) сайты, которые не создают им проблем с индексацией (т.е. раздел "Диагностика" в инструментах веб-мастера не содержит описание ошибок.

В результате я решил, что страница "404" должна формироваться для пользователя, но вовращаться с кодом "404". Для этого потребовалось внести несколько простых изменений:

Убираем из web.config перенаправление на PageNotFound.aspx, чтобы отключить 302 редирект:
<customErrors mode="On" defaultRedirect="GenericErrorPage.htm" />
Передаем управление странице PageNotFound.aspx сами. Для этого в файле Global.asax добавляем следующий код в обработчик ошибок уровня приложения:
void Application_Error(object sender, EventArgs e)
{
HttpException ex = Server.GetLastError() as HttpException;
if (ex != null && ex.GetHttpCode() == (Int32)HttpStatusCode.NotFound)
{
Server.Execute("PageNotFound.aspx", false); Server.ClearError();
}
}
То есть, если ошибка, это - "страница не найдена", нужно на самом деле выполнить PageNotFound.aspx и очистить стек ошибок (так как мы обработали эту ситуацию сами).
На самой странице PageNotFound.aspx добавляем следующий код, возвращающий статус 404 браузеру:
protected override void OnLoad(EventArgs e)
{
base.OnLoad(e);
Response.StatusCode = (Int32)HttpStatusCode.NotFound;
}

Все, теперь можно смотреть, что получилось:

Вот теперь совсем другое дело, нам вернулась наша страница, но уже с 404 кодом возврата. Теперь и пользователь и поисковик получат то, что мы хотим: один - "этого мы не нашли, но вы можете попробовать поискать что-то другое", второй - "такой страницы не существует".

И напоследок еще один совет. На вашей "404" странице кроме сообщения "Эта страница не найдена" вы можете разместить специальный "Google виджет для улучшения страницы 404". Это java script, который будет отображать примерно следующее:

Если вы можете поделиться своим опытом борьбы со списками ошибок, которые выводятся в инструментах веб-мастера - пишите, буду рад это с вами обсудить. И да будут к вам благосконны поисковые сервера! :)

Microsoft Chart Control

host.nospam@nospam.developernotes.net (Felix) — Sun, 14 Dec 2008 09:03:00 PST

Есть несколько типов элементов управления, которые очень часто используются в интерфейсе веб-приложений, но не входят в Visual Studio. Кто из вас не искал "симпатичный, но простенький календарик"? Или текстовое поле с минимальными возможностями форматирования (bold, italic, alignment)? Да, в сети полно таких компонент, многие бесплатны, многие являются OpenSource проектами, но их нужно искать ... выбирать ... проверять. Среди таких компонент попадаются отличные варианты, но за решениями от Microsoft стоят сотни и тысячи часов усилий по реализации и поддержке. А это значит - функциональность, все преимущества VS и IntelliSense и надежность (да-да, что бы там не говорили, у Microsoft очень жесткая политика разработки и тестирования; если вы пользовались сторонними компонентами Sheridan, Components Arts или Stingray то можете сравнить bug-листы и скорость их исправления).

Вот поэтому я всегда радуюсь, когда узнаю, что в составе VS появилось что-то новенькое. Хороший пример - библиотека jQuery. Она будет поставляться с 10-й версией Visual Studio и уже входит в инсталляцию ASP.NET MVC Beta. А недавно, семейство элементов управления от VS пополнилось еще одним очень полезным компонентом - Microsoft Chart Control.

Узнать об этом подробнее вы сможете в примерах от Microsoft. В использовании этой библиотеки может быть одно но: обязательное наличие .NET Framework 3.5 SP1. Если вас это не пугает, дальше идут сплошные достоинства, про комплектацию библиотеки можно смело сказать "полный фарш":

25 основных типов диаграмм с возможностью полной кастомизации (тьфу, звучит то как ... Но смысл вы же поняли? :)
куча поддерживаемых возможностей при выводе данных (больше 20 пунктов со сложными "диаграммными" терминами в документации)
интерактивность и поддержка AJAX
документация. Она содержит только подробное описание классов, за "getting started" нужно смотреть следующий пункт
Более 200 подробных примеров с исходными кодами на C# и Visual Basic
локализация (нужно загрузить Language Pack)
интеграция в Visual Studio (Toolbox, IntelliSense). Для этого опять таки нужно загрузить специальный Add-on для VS 2008
форум, посвященный Microsoft Chart Control. Причем форум, который мониторится сотрудниками Microsoft, так что вопросы здесь действительно закрываются конкретными ответами.

Если вы установите Chart компонент и он покажется вам до боли знакомым - не удивляйтесь :) Дело в том, что по сути - это Dundas Data Visualization controls. Microsoft взяла за основу исходные коды Dundas, и потратила кучу времени на доводку и адаптацию к своим стандартам. Правда при этом под ASP.NET мы лишились таких возможностей оригинала как скроллинг \ масштабирование, некоторых компонент UI (Toolbar, Context Menu, Property Pages) и Falsh анимации и ренедринга.

Microsoft Chart Control доступен в виде отдельной инсталляции для .NET Framework 3.5 и будет поставляться вместе с .NET Framework 4.0.

Так что на первый взгляд все выглядит очень привлекательно, ну а настоящее положение дел можно проверить только добавив этот компонент в свое приложение. Так что я буду рад услышать от вас отзывы о реальном использовании Microsoft Chart, пишите!

ADO.NET Entity Framework: мой доклад на Developer Days 2008

host.nospam@nospam.developernotes.net (Felix) — Sat, 06 Dec 2008 15:22:00 PST

Презентция "ADO.NET Entity Framework" на Developer Days 2008 (zip, 2.4Mb)

Это событие произошло еще в сентябре. Но в то время блог пребывал во временно-вечном состоянии "не пишу, потому что еще чуть-чуть - и будет новая версия, а новой версии нет - потому что нужно пусть и чуть-чуть, но времени" :) А ~~похва~~ рассказать очень хочется ...

Дело в том, что мне предложили прочитать один из докладов на Киевском Developer Days 2008, которые периодически устраивает Microsoft. Можно было даже выбрать одну из тем, всего их было 4:

Internet Explorer 8: нові можливості для розробників
Розробка застосувань за допомогою Windows Presentation Foundation 3.5 SP1 (из двух частей)
SilverLight 2: архітектура застосувань, створення елементів керування
.NET Framework 3.5 SP1: ADO.NET Entity Framework

Ближе всего мне была последняя - Entity Framework. Дело в том, что до недавнего времени все мои проекты были по сути интернет порталами. А значит новинки IE 8.0 там использовать пока бесмысленно - очень важно, чтобы приложение одинаково хорошо работало под всеми браузерами (а в случае IE - с целой линейкой, начиная с 6-й версии) Кстати, подружить 6-ю и 7-ю версии на одном компьютере мне так и не удалось, так что о существовании 6-й я вспоминаю только когда слышу фразу "да у вас весь дизайн поехал" :(. WPF к веб-приложениям прикручивать вроде некуда, а SilverLight не прикрутишь именно к порталам - поисковые сервера до сих пор не могут найти, что же там можно проиндексировать :)

А вот Entity Framework вполне можно использовать для создания объектной модели. Так что я запустил Power Point и набрал на первой странице "ADO.NET Entity Framework".

А вот дальше начались проблемы. Как-то так получилось, что c Power Point я раньше ничего не делал. "Не беда", подумал я, "есть масса презентаций, что-то, а copy-paste за долгие годы разработки я освоил профессионально". Но коварный PP всячески надо мной издевался: красивые и большие заголовки при копировании становились едва заметными, а яркие и сочные оранжевые блоки катастрофически бледнели (угу, потом я понял, что есть такое понятие - палитра). Вобщем на борьбу с PP времени я потратил может и не больше, чем на доклад, но очень прилично.

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

На доклад отводился час. Я засек время, запустил презентацию и глупо улыбаясь стене произнес "День добрый! Меня зовут Сергей Мысливый и мы поговорим с вами об Entity Framework" ...

Хм, вобщем в первый раз это заняло больше двух часов. Я схватился за голову и начал безжалостно кромсать текст доклада. Сначала чуть-чуть, потом еще чуть-чуть ... Вобщем через некоторое время, когда я произносил финальную для доклада (но к сожалению, не для выступления :) фразу "Ну, а теперь вопросы?" я укладывался минут в 45.

Сама конференция проводилась в новом офисе Microsoft на ул. Жилянской (добиратся туда можно как от м. Университет, так и от Вокзальной, причем в обоих случаях придется пройтись). Моя презентация начинался после обеда, так что пока можно было не волноваться и спокойно слушать других докладчиков. Но всему хорошему приходит конец и вот - я лихорадочно пережевываю обед, паралельно обдумывая сразу несколько вещей:

не слишком ли заметно, как я волнуюсь?
может бросить обед, подключить свой ноутбук к проектору и только убедившись что все работает - доесть?
как не растеряться и не забыть первую фразу (а за ней и все остальные)?

Но все обошлось (по крайней мере, пока мне так кажется). После стольких повторений перед стенкой, доклад я протарабанил не сильно сбиваясь и даже смог ответить на все вопросы. Из забавного ... когда я подключил свой ноутбук к проектору, до начала доклада оставалось еще минут 20. Их я провел пытаясь непринужденно общаться с друзьями, а на самом деле постоянно повторяя про себя как попугай "День добрый! Меня зовут ..." ну и дальше. В это время мой ноутбук заскучал и включил хранитель экрана, все это естественно выводилось на проектор. Хранитель у меня безобидный - просто выводит фотографии из указанной папки в произвольном порядке (есть такая стандартная штука в Windows Vista). Первые пару секунд я лихорадочно вспоминал, на какую именно папку он настроен в этот раз?! но уф, пронесло, это были нейтральные (и очень мне симпатичные) фотографии из Барселоны :)

Ну а потом, уже после доклада, я забыл отцепить и выключить микрофон. Так как доклад был последним, его у меня забрали не сразу. Поэтому друзья рассказали, что мои разговоры еще минут 10 транслировались пустеющему залу.

Кстати, в первый раз по другому отнесся к заполнению анкет, которые обычно раздаются перед мероприятием. Еще бы, ведь докладам ставят оценки и мне было чертовски любопытно, что же там пишут! Но если у первых докладов еще были шансы на какую-то объективность, оценки моего доклада зависели только от щедрости слушателей. Он был последним, а так как анкеты меняли на футболки ... ну, вобщем вы поняли. Самые нетерпеливые оценили все доклады ее до 12 (перерыв и кофе), а остальные (кстати, и я тоже :) - до обеда.

Так что перед самим докладом вышел Сергей Байдачный и поблагодарил всех за хорошие прогнозы. Из зала пошутили, что мол теперь докладчику придется постараться, чтобы не обмануть ожидания. Я затравленно улыбнулся, запустил презентацию и произнес "День добрый! Меня зовут ...".

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

В начале статьи я разместил ссылку на файл с презентацией моего доклада. Обратите внимание на текстовки к каждому слайду. Чтобы было немного понятнее, я раскидал по ним текст своего доклада. Конечно, это скорее памятка о чем нужно сказать, но все равно, с ними немного понятнее.

Еще в текстовки включены куски, которые я опустил в реальном докладе из-за огрничений по времени (они отделены текстом "[Вырезано из финальной версии, чтобы уложится вовремя]"). Так что эту версию презентации смело можно назвать авторской :)