При использовании фреймворка ASP.NET MVC, есть возможность использования серверной и клиентской валидации при помощи атрибутов из пространства
имен DataAnnotations.

Для отображения ошибок полей ввода, можно воспользоваться расширениями для отображения сообщений об ошибках, входящими в фреймворк ASP.NET MVC:

Html.ValidationMessage
Html.ValidationMessageFor
Html.ValidationSummary

Расширения Html.ValidationMessage и Html.ValidationMessageFor, предназначены для отображения ошибок ввода для конкретного поля, а Html.ValidationSummary — отображает все ошибки, как относящиеся к полям, так и добавленные в словарь ModelState вручную из контроллера.

У расширения Html.ValidationSummary имеется булевый атрибут, который управляет отображением ошибок, при значении true будут исключены ошибки полей и отображены только ошибки модели, а при значении false (оно включено по умолчанию) будут показаны и ошибки полей и ошибки модели.

При использовании нижеприведенного кода для своего приложения, я столкнулся с одной странностью. При возникновении исключения в строке:

MembersManager.RegisterMember(member);

в секции catch добавляется ошибка в словарь ModelState, следующим образом:

ModelState.AddModelError("error", ex.Message);

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

Как описано на сайте MSDN, для этого необходимо передать для  ValidationSummary, в качестве параметра значение true. Но при использовании следующего кода в ValidationSummary не выводится совсем никаких ошибок:

Модель (Model):

public class Member
{
    [Required(ErrorMessage = "*")]
    [DisplayName("Login:")]
    public string Login { get; set; }

    [Required(ErrorMessage = "*")]
    [DataType(DataType.Password)]
    [DisplayName("Password:")]
    public string Password { get; set; }
    [Required(ErrorMessage = "*")]
    [DataType(DataType.Password)]
    [DisplayName("Confirm Password:")]
    public string ConfirmPassword { get; set; }
}

Контроллер (Controller):

[HttpPost]
public ActionResult Register(Member member)
{
    try
    {
        if (!ModelState.IsValid)
            return View();

        MembersManager.RegisterMember(member);
    }
    catch (Exception ex)
    {
        ModelState.AddModelError("error", ex.Message);
        return View(member);
    }
}

Представление (View):

<% using (Html.BeginForm("Register", "Members", FormMethod.Post, new { enctype = "multipart/form-data" })) {%>

    <p>
        <%= Html.LabelFor(model => model.Login)%>
        <%= Html.TextBoxFor(model => model.Login)%>
        <%= Html.ValidationMessageFor(model => model.Login)%>
    </p>

    <p>
        <%= Html.LabelFor(model => model.Password)%>
        <%= Html.PasswordFor(model => model.Password)%>
        <%= Html.ValidationMessageFor(model => model.Password)%>
    </p>

    <p>
        <%= Html.LabelFor(model => model.ConfirmPassword)%>
        <%= Html.PasswordFor(model => model.ConfirmPassword)%>
        <%= Html.ValidationMessageFor(model => model.ConfirmPassword)%>
    </p>

    <div>
        <input type="submit" value="Create" />
    </div>

    <%= Html.ValidationSummary(true)%>
<% } %>

После длительного поиска на просторах интернет и изучения исходных кодов фреймворка ASP.NET MVC, было найдено решение, которое оказалось до жути банальным.

Как выяснилось ValidationSummary, ищет ошибки модели, которые привязаны к полям (в качестве ключа словаря ModelState передаются имена полей). Поэтому достаточно было в качестве ключа, при добавлении ошибки в ModelState, передать пустую строку

ModelState.AddModelError(String.Empty, ex.Message);

и все стало работать именно так, как и задумывалось

P.S. При использовании классов LINQ To SQL, может возникнуть необходимость пробежаться по набору EntitySet при помощи цикла foreach, но тут может возникнуть ошибка приведения типов. По ссылке можно увидеть решение данной проблемы.

А вы знаете как заработать деньги в интернете — заходите, расскажем.

Верстая очередную HTML страничку, случайно наткнулся на интересную особенность FireFox. Оказывается, при определенных манипуляциях (или положении звезд) в FireFox не будет срабатывать кнопка Submit (<input type=”submit” />).

Расскажу об этом поподробнее, с пошаговыми инструкциями

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

Итак, создаем простенькую HTML страничку:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
  <title>Test Page</title>
  <meta http-equiv="content-type" content="text/html; charset=utf-8" />
</head>
<body>
  <form action="/login.php" method="post">
  <p>
    <label for="login">Login:</label>
    <input name="login" />
  </p>
  <p>
    <label for="password">Password:</label>
    <input name="password" type="password" />
  </p>
  <p>
    <input type="submit" value="Sign In" />
  </p>
  </form>
</body>
</html>

Открываем ее напрямую с жесткого диска.

Во всех основных браузерах (IE, Opera, Google Crome, Safari и FireFox), и пробуем нажать на кнопку “Sign In”. Почти во всех браузерах произойдет отправка данных формы методом post, на сценарий login.php. И только в одном FireFox этого не произойдет. При нажатии на Submit не произойдет перехода на сценарий указанный в атрибуте action тега form.

Долго пытаясь разобраться в чем же, собственно, проблема – я случайно убрал слэш из атрибута action:

<form action="login.php" method="post">

и, о радость, все заработало. Я был очень удивлен, но когда попробовал этот же файл (с начальным слэшем в атрибуте action) задеплоить на сервер и получить его уже оттуда, то оказалось, что при получении файла с сервера по протоколу http://, а не file:// — все работает правильно во всех браузерах, независимо от того есть слэш в начале или же он отсутствует.

Вот мне интересно – это бага или все же фича Firefox?

Одним из способов уменьшения времени загрузки страниц веб-сайтов является уменьшение CSS и JavaScript файлов.

Каким способом это можно сделать?

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

Для минимизации CSS и JavaScript файлов существует огромное множество инструментов. Но одним из наилучших на мой взгляд, является YUI Compressor от компании Yahoo.

YUI Compressor позволяет сократить размер CSS и JavaScript файлов на 40-60%. YUI Compressor написан на языке Java и для своего запуска требует виртуальную машину Java (версии >= 1.4).

При работе с Visual Studio будет немного неудобно использование данного инструмента, поэтому был создан порт данного минимайзера для платформы .NET – YUI Compressor for .NET.

Основные возможности YUI Compressor for .NET:

• YUI Css сжатие.
• YUI JavaScript сжатие.
• Интеграция с Visual Studio post-build событиями. По этому адресу можно найти более подробную инструкцию.
• MSBuild таски, могут быть использованы в решении Web Deployment Project.
• MSBuild таски, также могут собирать все сжатые файлы в один (aka. файла объединения).
• Возможность обработки, различных типов кодировки (например Unicode) и ThreadCulture.
• Может обрабатывать групповые задачи (например *. JS).

Для быстрого подключения YUI Compressor к проекту добстаточно добавить в проект файл MSBuild.xml и прописать путь к нему в post-build event.

Пример простейшей задачи минимизации файлов в MSBuild файле:

<?xml version="1.0" encoding="utf-8"?>
<Project xmlns="http://schemas.microsoft.com/developer/MsBuild/2003">
    <UsingTask
        TaskName="CompressorTask"
        AssemblyFile="..\..\Projects\Yahoo.Yui.Compressor\Model\bin\Debug\Yahoo.Yui.Compressor.dll" />
    <!-- The .NET 2.0 version of the task .. and yes .. that's Model.Net20 folder listed twice .. i know i know...
    <UsingTask
        TaskName="CompressorTask"
        AssemblyFile="..\..\Projects\Yahoo.Yui.Compressor\Model.Net20\Model.Net20\bin\Debug\Yahoo.Yui.Compressor.NET20.dll" />
    -->

    <!-- Define the output locations. These can be set via the msbuild command line using
         /p:CssOutputFile=$(TargetDir)../whatever...
         /p:JavaScriptOutputFile=$(TargetDir)../whatever...

         If they are not supplied or are empty, then we the value whatever is supplied, below.
    -->
    <PropertyGroup>
        <CssOutputFile Condition=" '$(CssOutputFile)'=='' ">SylesSheetFinal.css</CssOutputFile>
        <JavaScriptOutputFile Condition=" '$(JavaScriptOutputFile)'=='' ">JavaScriptFinal.css</JavaScriptOutputFile>
    </PropertyGroup>

    <Target Name="MyTaskTarget">
        <!--
            ItemGroup\CssFiles or ItemGroup\JavaScriptFiles: add zero to many files you wish to include in this compression task.
            Don't forget, you can use the wildcard (eg. *.css, *.js) if you feel up to it.
            Finally, at least one item is required - either a css file or a js file.

            CssFiles/JavaScriptFiles data format: Please do not touch this.
            DeleteCssFiles: [Optional] True | Yes | Yeah | Yep | True | FoSho | Fo Sho. Default is False. Anything else is False. (eg. blah = false, xxxx111 = false, etc)
            CssCompressionType: YuiStockCompression | MichaelAshsRegexEnhancements | HaveMyCakeAndEatIt or BestOfBothWorlds or Hybrid; Default is YuiStockCompression.
            ObfuscateJavaScript: [Optional] refer to DeleteCssFiles, above.
            PreserveAllSemicolons: [Optional] refer to DeleteCssFiles, above.
            DisableOptimizations: [Optional] refer to DeleteCssFiles, above.
            EncodingType: [Optional] ASCII, BigEndianUnicode, Unicode, UTF32, UTF7, UTF8, Default. Default is 'Default'.
            DeleteJavaScriptFiles: [Optional] refer to DeleteCssFiles, above.
            LineBreakPosition: [Optional] the position where a line feed is appened when the next semicolon is reached. Default is -1 (never add a line break).
            0 (zero) means add a line break after every semicolon. (This might help with debugging troublesome files).
            LoggingType: None | ALittleBit | HardcoreBringItOn;  Hardcore also lists javascript verbose warnings, if there are any (and there usually is :P ).
            ThreadCulture: [Optional] the culture you want the thread to run under. Default is 'en-gb'.
            IsEvalIgnored: [Optional] compress any functions that contain 'eval'. Default is False, which means a function that contains 'eval' will NOT be compressed. It's deemed risky to compress a function containing 'eval'. That said, if the usages are deemed safe this check can be disabled by setting this value to True.
        -->
        <ItemGroup>
            <!-- Single files, listed in order of dependency -->
            <CssFiles Include="StylesheetSample1.css"/>
            <CssFiles Include="StylesheetSample2.css"/>
            <CssFiles Include="StylesheetSample3.css"/>
            <CssFiles Include="StylesheetSample4.css"/>

            <JavaScriptFiles Include="jquery-1.3.2.js"/>

            <!-- All the files. They will be handled (I assume) in alphabetically. -->
            <!-- <CssFiles Include="*.css" />
            <JavaScriptFiles Include="*.js" />
            -->
        </ItemGroup>
        <CompressorTask
            CssFiles="@(CssFiles)"
            DeleteCssFiles="false"
            CssOutputFile="$(CssOutputFile)"
            CssCompressionType="YuiStockCompression"
            JavaScriptFiles="@(JavaScriptFiles)"
            ObfuscateJavaScript="True"
            PreserveAllSemicolons="False"
            DisableOptimizations="Nope"
            EncodingType="Default"
            DeleteJavaScriptFiles="false"
            LineBreakPosition="-1"
            JavaScriptOutputFile="$(JavaScriptOutputFile)"
            LoggingType="ALittleBit"
            ThreadCulture="en-au"
            IsEvalIgnored="false"
            />
    </Target>
</Project>

а знаете ли вы, что в SEO денег нет.

Вчера вышел второй релиз кандидат фреймворка ASP.NET MVC 2.

Отличий от RC немного, основной упор сделан на улучшение модельной валидации.

Улучшения

• Для новых проектов обновлен скрипт MicrosoftAjax.js для совместимости с версией ASP.NET Ajax которая включена в ASP.NET 4. Обновленный скрипт совместим с обеими версиями ASP.NET 3.5 SP1 и ASP.NET 4.
• Улучшена производительность большой части кода фреймворка.
• У типа данных TempDataDictionary появился новый метод Peek, который читает данные из словаря TempData без удаления их из этого словаря.
• Такие методы-хелперы, как Html.EditorFor и Html.DisplayFor по умолчанию показывают только простые свойства. Если же необходимо отображать комплексные свойства, то можно создать шаблон для отображения любого набора свойств.
• Контекстное меню Add View в Visual Studio позволяет создавать представления для удаления данных. У шаблона List появилась ссылка Delete для удаления выбранного пункта.
• Валидационные хелперы больше не рендерят префикс “form0” для атрибута id.
• Хелперы для выражений генерируют правильные имена в атрибуте name, когда выражение содержит массив или коллекцию элементов. Например, значение атрибута name, сгенерированного хелпером  Html.EditorFor (m => m.Orders[i]), для первого заказа в списке — будет установлено в Orders[0].
• Новый тип UrlParameter позволяет удалить значения по умолчанию в роутинге уже после запуска URL роутинга. Если входной параметр роутинга имеет тип UrlParameter.Optional, экземпляр MvcHandler удалит из коллекции RouteData.Values дефолтное определение роутинга. Это облегчает связь с моделями, которые имеют такое же свойство с именем ID, поэтому дефолтное значение параметра роутинга ID не будет конфликтовать со связанной операцией.
• Чистый шаблон проекта включает небольшой файл Site.css, который содержит стили, используемые в валидационных хелперах таких как Html.ValidationSummary и Html.ValidationMessage.
• Темплейтные файлы Т4 могут использовать дерективу <#@ output extension=".ext" #>, чтобы указать расширение генерируемого файла.

Исправления

• SessionStateTempDataProvider больше не сохраняет значения TempData в сессии, когда нету временных данных для сохранения.
• Метод GetValue из класса FormCollection позволяет сохранять пустые строковое значения.
• Появилась возможность програмно запретить клиентскую валидацию для кнопки submit, даже если у кнопки не установлен атрибут name, до этого, для аналогичного действия, необходимо было обязательно устанавливать атрибут name.
• Неудачная проверка на клиенте, предотвращает отправку данных на сервер для Ajax формы.

Теперь, с нетерпением ждем выхода релиза фреймворка ASP.NET MVC 2.

Если вам необходима разработка сайта, то мы Вам поможем.

При локализации веб-сайтов, написанных с использованием технологии ASP.NET либо ASP.NET MVC необходимо добавить в проект файл ресурсов (*.resx). Приведу пример использования глобального файла ресурсов.

B Visual Studio 2008 для начала в проект необходимо добавить папку App_GlobalResources для этого щелкаем правой кнопкой на проекте:

Add –> Add ASP.NET Folder –> App_GlobalResources

После того, как папка создана, в нее необходимо добавить файл ресурсов, который станет основным для проекта. Щелкаем правой кнопкой на App_GlobalResources:

Add –> New Item

В появившемся диалоговом окне, создания нового элемента, выбираем Resources File, а в поле Name вводим желаемое имя файла ресурсов.

После добавления файла в проект, по умолчанию откроется, встроенный в Visual Studio, редактор ресурсов (Managed Resources Editor), при помощи которого можно добавлять ресурсы в проект (чаще всего это строки).

После добавления необходимых строк в файл ресурсов и его сохранения запускается генератор файлов ресурсов ResXFileGenerator, который генерирует класс со статичными полями, то есть будет сгенерирован строго типизированный класс для доступа к ресурсам. По умолчанию этот класс будет создан в пространстве имен Resources с именем, которое было задано в качестве имени файла. Модификатор доступа (Access Modifier), как для класса, так и для его полей по умолчанию internal, что не всегда приемлемо, в частности для атрибутов валидации в проектах ASP.NET MVC. Поэтому иногда необходимо изменить модификатор доступа на public, но вот тут начинаются проблемы. Не могу до сих пор понять в каких случаях, но довольно часто, поле Access Modifier в редакторе ресурсов недоступно. Если просто изменить модификаторы доступа в сгенерированном файле, то при следующем сохранении фала ресурсов эти изменения пропадут.

После активного гугления было найдено довольно хорошее решение — Extended Strongly Typed Resource Generator. Для его подключения, необходимо в свойствах фйала ресурсов

В свойстве Custom Tool, необходимо поменять значение со значения по умолчанию GlobalResourceProxyGenerator на ResXFileCodeGeneratorEx. При желании можно поменять стандартное пространство имен, изменив для этого свойство Custom Tool Namespace. После таких манипуляций, при каждом сохранении файла ресурсов Access Modifier будет установлен в public.

технадзор строительства

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

HTML — это язык для описания разметки документов. Его основу составляют теги и атрибуты. С помощью языка разметки, мы не пишем программы, как при помощи языка программирования, а только определяем структуру документа, то есть, описываем, с помощью каких-то служебных слов (тегов), как должна отображаться информация (контент: текст, картинки, видео).

Для отображения (интерпретации) странички сверстанной с помощью HTML, необходимы специальные программы — браузеры (по другому их еще называют интернет-обозревателями). Браузер читает последовательно файл HTML и рисует (рендерит) блоки в нужном месте, и с необходимыми атрибутами отображения.

HTML содержит ограниченный набор тегов, выучить их несложно. Каждый тег, в свою очередь, может иметь какое-то количество атрибутов, либо не иметь их вовсе. Некоторые атрибуты в тегах могут быть обязательными, некоторые — опциональные.

Тег - это инструкция, которая укажет браузеру, какой блок нарисовать и, возможно, в каком месте и каким стилем его вывести, но второе утверждение принято выносить в CSS.  Тег это служебная инструкция размещенная между символами меньше (<) больше (>). Теги могут быть открывающимися и закрывающимися. Например: <div> - открывающий тег, </div> - закрывающий тег. Открывающий тег указывает на начало какого либо блока, а закрывающий — на завершение этого блока.

Атрибут — это уточнение для браузеров, как поточнее нарисовать тег, атрибуты описываются внутри открывающего тега в виде коллекции имя="значение". Например: <div class="header">.

Есть несколько спецификаций (по другому версий) языка HTML. Различаются они правилами описания тегов и атрибутов а так же набором поддерживаемых тегов и атрибутов.  На данный момент активнее всего используется HTML версии 4.01 и XHTML 1.0. Активно ведется разработка HTML 5.0 и XHTML 2.0.

Файлы HTML можно просматривать в двух видах. Один, собственно, результат обработки (рендеринга) описанной разметки в программах просмотра (браузерах). И второй в сыром виде (исходный текст). Браузеры имеют одну нехорошую особенность, не все они одинаково интерпретируют разметку и один и тот же HTML может дать разную результирующую картину на двух разных браузерах и, даже, на одном браузере разных версий. Так же, на отображение страницы в браузере, очень сильно влияет правильность указания DOCTYPE.

Для начала достаточно изучить наиболее распространенные теги HTML, их будет достаточно для базовой верстки страниц:

• <html> — начало документа HTML. Должен находится в начале документа, или сразу после указания DOCTYPE.
• <head> — заголовок документа, это невидимый элемент в котором помещается служебная информация: заголовок, ссылки на подключение CSS и JavaScript файлов, ключевые слова, описание документа.
• <title> — заголовок страницы, текст который будет выведен в заголовке браузера.
• <link> — с помощью данного тега можно подключить CSS файлы.
• <body> — тело документа. Отсюда начнется отображение (рендеринг) блоков.
• <div> — прямоугольный блок.
• <table> — таблица.
• <tr> — строка в таблице.
• <td> — ячейка в таблице.
• <a> — ссылка на другой документ либо веб-сайт.
• <p> — абзац тектста.
• <input> — элемент ввода.
• <span> — небольшой текст.

Полный список тегов и их атрибутов можно найти не ресурсе HTML Book.

Каждый тег может быть расширен атрибутами. Некоторые теги вообще бессмысленны, если в них не указаны атрибуты. Как, например, тег <a>, если в нем не указать атрибут href, то использование данного тега будет бессмысленно, так как не будет указания ссылку на какой документ отрендерить.

В следующих постах более подробно рассмотрим данные понятия и научимся создавать документы HTML.

Изучение HTML можно освоить на ноутбуках apple. А цены можно узнать на єтом сайте.

Ну вот и дошла пора более серьезно заняться настройкой своего Apache сервера на рабочей машине.

Так как на моем компе установлена Ubuntu Linux, а установка приложений с помощью менеджера пакетов Synaptic — сплошное удовольствие, то получилось так, что я установил с его помощью Apache и мне хватало его дефолтных установок. Но захотелось мне навести красоту, разместить несколько веб-сайтов и иметь к ним доступ по разным доменным именам.

Итак, имеем задачу:

Настроить несколько веб-сайтов, на локальном сервере Apache2, установленного на рабочей машине с Ubuntu Linux, и чтобы доступ к ним был по адресам, например таким:

• 1й сайт — www.test1.my и test1.my
• 2й сайт — www.test2.my и test2.my

и так далее, в том же духе.

При попытке привести все к красоте, возникло несколько интересных ошибок, которые, надеюсь нелишне описать.

Итак, первое, в Ubuntu состав директории /etc/apache2 немного отличается от привычных директорий настройки Apache в Unix-подобных системах.

conf.d/
sites-available/
sites-enabled/
mods-available/
mods-enabled/
  apache2.conf
  envvars
  httpd.conf
  ports.conf

В Ubuntu основным файлом настройки Apache2 является не httpd.conf, а apache2.conf, но тут он играет роль системного файла, в котором собраны основные и самые важные настройки сервера.

А вот файл httpd.conf — пустой и предназначен для добавления дополнительных настроек, он включен в основной файл настройки apache2.conf

В файле envvars описаны переменные среды, необходимые для функционирования Apache-сервера.

В ports.conf вынесены настройки портов на которые можно будет подключиться к серверу или конкретному сайту на нем.

В папке conf.d находятся дополнительные конфигурационные файлы.

Для описания всех доступных сайтов используется папка sites-available в которой расположены файлы с описанием виртуальных хостов — VirtualHosts, опубликованные же сайты находятся в папке sites-enabled в виде ссылок на файлы доступных сайтов из папки sites-available.

Таким же образом в папках mods-available и mods-enabled настраивается доступность модулей используемых сервером.

Разобравшись со структурой файлов и папок, уже можно приступать к настройке. Первым делом создаем новый файл в папке sites-available, с именем хоста, так будет понятнее при просмотре директории.

#sudo touch test1.my

после этого с помощью любого доступного текстового редактора добавляем в этот файл следующие строки

<VirtualHost *:80>
    ServerName test1
    ServerAlias test1.my www.test1.my
    DocumentRoot /var/www/test1.my/www
</VirtualHost>

таким образом можно создать необходимое колличество виртуальных хостов и направить их в нужные директории на винчестере.

Теперь необходимо как-то научить нашу операционную систему распознавать домен .my. Для этого достаточно прописать необходимые строки в файле /etc/hosts, например так:

127.0.0.1    test1.my        www.test1.my

Так, теперь мы имеем настройку сайта как виртуального хоста (VirtualHost), имеем настроенный доменный адрес, но сайт еще не доступен для просмотра в браузере. А почему? А потому, что для начала необходимо разместить ссылку на VirtualHost в папку sites-enabled, и перечитать конфигурацию сервера Apache. Для создания ссылки можно выполнить такую команду:

#sudo a2ensite /etc/apache2/sites-available/test1.my

и перечитаем параметры:

#sudo /etc/init.d/apache2 reload

приведеная команда, перечитает параметры настройки сервера без его перезагрузки.

И вот тут мы столкнемся со второй неприятностью, не критической, но неприятной. После перечитки параметров будет выведено информационное сообщение:

Could not reliably determine the server's fully qualified domain name, using 127.0.0.1 for ServerName

Что-то некрасиво получается, зачем нам такое. Но, мы помним, что у нас есть файл httpd.conf в котором желательно прописывать дополнительные настройки. Итак, открываем этот файл в текстовом редакторе, не забываем, что это надо делать с правами суперпользователя, и прописываем туда такую строчку

ServerName имя_вашего_сервера

сохраняем, закрываем файл и перечитываем параметры настройки:

#sudo /etc/init.d/apache2 reload

Сообщение пропало и теперь мы имеем красиво настроенный веб-сервер Apache. Сейчас для добавления новых сайтов достаточно создать файл виртуального хоста, вписать в него параметры настройки для хоста, добавить его в видимые хосты и перечитать параметры. Вот так вот, оказывается, все просто делается в нелегком админском деле.

После переустановки Windows и, соответственно, всего инструментария для разработки приложений, столкнулся с забавной ситуацией: невозможно было запустить отладчик из под Visual Studio 2008, для отладки веб сайта, написанного на ASP.NET 2.0.

При попытке запустить приложение в режиме дебага, выскочила ошибка «Unable to start debugging on the web server. The web server could not find the requested resource».

После длительного поиска в сети, было найдено решение, которое оказалось совсем нетривиальным.

Для того, чтобы полечить данную проблему, необходимо установить приложение UrlScan от Microsoft.

UrlScan — это утилита безопасности от Microsoft, которая позволяет отсекать определенные типы HTTP запросов на Internet Information Services (IIS). Больше информации об этой утилите можно найти на сайте Microsoft UrlScan.

При правильном конфигурировании данной утилиты, ошибка Unable to start debugging исчезает.Далее приведу шаги, которые необходимо выполнить для корректной настройки UrlScan.

Для начала воспользуемся следующей инструкцией: How to configure URLScan to protect ASP.NET Web applications.

Данная настройка сделает доступным настройку ASP.NET приложений, но не исправит ошибку. Поэтому воспользуемся следующей инструкцией Error: The Web Server Has Been Locked Down and Is Blocking the DEBUG Verb.

Настройка DEBUG Verb в секции AllowVerbs файла Urlscan.ini.

• Находим файл Urlscan.ini. Обычно он должен находится в директории:
  C:\WINNT\System32\Inetsrv\urlscan
• Сделаем резервную копию файла настроек Urlscan.old.
• Открываем файл настроек Urlscan.ini в любом текстовом редакторе.
• В Urlscan.ini находим секцию [AllowVerbs]. Добавляем параметр DEBUG в секцию [AllowVerbs]. Если присутствует закомментированный параметр ;DEBUG в секции [AllowVerbs], то просто раскоментируем даный параметр убрав точку с запятой.
• Смотрим секцию [DenyVerbs]. Если там присутствует параметр DEBUG удаляем, либо комментируем его.
• Сохраняем файл настроек.
• Перегружаем IIS.

После этих нехитрых манипуляций, наслаждаемся возможностью дебага в Visual Studio.

На днях мне понадобилось реализовать отправку данных формы на сервер (submit формы), но с предварительной обработкой события формы onsubmit. Все бы ничего, если бы это можно было бы сделать при обычном нажатии на кнопку submit, но задача была немного усложнена тем, что сабмитить форму надо было автоматически, а не по запросу пользователя. В моем случае — по таймеру.

Естественно, при отправке данных на сервер, необходимо было воспользоваться JavaScript методом form.submit (). Каково же было мое удивление, когда я обнаружил, что метод отправки данных с помощью кнопки submit и работа JavaScript метода формы submit () кардинально отличаются.

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

Пример отправки данных на сервер (post) с помощью обычной кнопки <input type="submit" /> и предварительная обработка onsubmit будет выглядеть так:

<html>
<body>
  <form name="myform" onsubmit="alert('Отправка данных на сервер')" method="post">
    <input type="text" name="data" value="Данные" />
    <a href="javascript:document.myform.submit()">Отправить</a>
  </form>
</body>
</html>

при таком коде HTML, поведение формы будет следующим: если нажать кнопку «Отправить», сначала выскочит окошко с предупреждением об отправке данных на сервер, а после нажатия на кнопку «ОК», данные будут отправлены на сервер.

А что же будет, если заменить кнопку submit на JavaScript метод form.submit ()?

<html>
<body>
  <form name="myform" onsubmit="alert('Отправка данных на сервер')" method="post">
    <input type="text" name="data" value="Данные" />
    <a href="javascript:document.myform.submit()">Отправить</a>
  </form>
</body>
</html>

а вот в этом случае, и произойдет то самое, странное поведение формы — событие onsubmit не сработает, но данные будут отправлены на сервер.

После длительных опытов, было определено, что браузеры не следуют спецификации HTML. События обрабатываются только действиями пользователя, но не программными действиями.

А что же по этому поводу говорит спецификация W3C и основные производители браузеров.

Спецификация W3C Document Object Model (DOM) Level 2 HTML Specification говорит, что метод  submit () — «submits the form. It performs the same action as a submit button.» (сабмитит форму. Определяет то же действие, что и кнопка submit).

Производитель браузера FireFox, компания Mozilla сообщает, что onsubmit «Executes JavaScript code when a submit event occurs; that is, when a user submits a form.» (выполняет JavaScript код, когда возникает событие submit; это происходит в тот момент, когда пользователь сабмитит форму). Заметьте, что они уточняют «когда пользователь...», это в принципе исключает сабмит формы при вызове метода JavaScript.

Так же пишет и компания Netscape/Sun.

У Microsoft более лаконичное описание, «The submit method does not invoke the onsubmit event handler.» (Метод submit не вызывает событие onsubmit).

Как же выйти из этой ситуации?

Одним из решений может быть создание невидимой кнопки submit и вызов ее метода click (). Но это не сильно красивое решение. Поэтому можно подключить библиотеку jQuery и написать несколько строк кода на JavaScript для программной генерации событий.

$.fn.fireEvent = function(eventType) {
  return this.each(function() {
    if (document.createEvent) {
      var event = document.createEvent("HTMLEvents");
      event.initEvent(eventType, true, true);
      return !this.dispatchEvent(event);
    } else {
      var event = document.createEventObject();
      return this.fireEvent("on" + eventType, event)
    }
  });
};

Использовать данный метод очень просто. С помощью селектора jQuery находим нужный нам объект и вызываем метод fireEvent (), передав ему в качестве параметра, имя нужного события, без приставки on.

$("myform").fireEvent("submit");

На просторах сети, я находил еще одно решение — это использование метода trigger (), вместо метода fireEvent (), только он тоже не работает так как надо, потому и не буду его приводить тут.

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

Последних два дня, работая в Microsoft Visual Studio 2008, увидел одну неприятную особенность: при запуске сайта из среды Visual Studio, сайт по-умолчанию открывался не в Mozilla FireFox, который у меня в системе установлен браузером по-умолчанию, а в Internet Explorer. Меня такая ситуация в корне не устраивает, так как мне намного приятнее работать в «Огненном Лисе», а не в «Ослике».

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

Рис. 1. Браузер по-умолчанию в Visual Studio

Если в студии загружен разрабатываемый веб-сайт, то щелкаем в Solution Explorer правой кнопкой мыши на любом из файлов aspx, в появившемся контекстном меню (рис. 1) выбираем пункт меню Browse With..., после чего появиться окошко со списком прописанных в студии браузеров (рис. 2). Если в этом окошке отсутствует браузер FireFox, то просто необходимо добавить его, и установить браузером по-умолчанию.

Рис. 2. Установка FireFox браузером по-умолчанию

В принципе, таким образом можно, настроить Visual Studio, чтобы она открывала разрабатываемые сайты в вашем любимом браузере: Mozilla FireFox, Safari, Opera или Google Chrome.