ASP.NET MVC 2: Controller.File

Тем, кто решит вернуть пользователю файл с кириллическим именем, следует учесть, что такое имя будет воспринято только Firefox'ом (тестировал на версии 3.6), Chrome (тестировал на версии  8.0) и IE (тестировал на версии 8.0) заменят имя на имя действия контроллера.

В принципе, поведение объяснимо.

Пример.

public ActionResult Plain(string text)
{
   File(text.ToBytes(), "text/plain", "Текст.txt");
}

Файрфокс отобразит в диалоге сохранения файла: "Текст.txt", Хром же, как и Эксплорер, отобразят "Plain.txt".

Как вариант решения может быть использована транслитерация.

Пример.

public static class TranslitExtensions
{
    private static readonly Dictionary<string, string> letters 
        = new Dictionary<string, string>
        {
            {"№", "N"},
            {"а", "a"},
            {"б", "b"},
            {"в", "v"},
            {"г", "g"},
            {"д", "d"},
            {"е", "e"},
            {"ё", "yo"},
            {"ж", "zh"},
            {"з", "z"},
            {"и", "i"},
            {"й", "j"},
            {"к", "k"},
            {"л", "l"},
            {"м", "m"},
            {"н", "n"},
            {"о", "o"},
            {"п", "p"},
            {"р", "r"},
            {"с", "s"},
            {"т", "t"},
            {"у", "u"},
            {"ф", "f"},
            {"х", "h"},
            {"ц", "c"},
            {"ч", "ch"},
            {"ш", "sh"},
            {"щ", "sch"},
            {"ъ", "j"},
            {"ы", "i"},
            {"ь", "j"},
            {"э", "e"},
            {"ю", "yu"},
            {"я", "ya"},
            {"А", "A"},
            {"Б", "B"},
            {"В", "V"},
            {"Г", "G"},
            {"Д", "D"},
            {"Е", "E"},
            {"Ё", "Yo"},
            {"Ж", "Zh"},
            {"З", "Z"},
            {"И", "I"},
            {"Й", "J"},
            {"К", "K"},
            {"Л", "L"},
            {"М", "M"},
            {"Н", "N"},
            {"О", "O"},
            {"П", "P"},
            {"Р", "R"},
            {"С", "S"},
            {"Т", "T"},
            {"У", "U"},
            {"Ф", "F"},
            {"Х", "H"},
            {"Ц", "C"},
            {"Ч", "Ch"},
            {"Ш", "Sh"},
            {"Щ", "Sch"},
            {"Ъ", "J"},
            {"Ы", "I"},
            {"Ь", "J"},
            {"Э", "E"},
            {"Ю", "Yu"},
            {"Я", "Ya"}
        };

    /// <summary>
    /// Performs translation from Russian to Translit.
    /// </summary>
    /// <param name="russian">String in Russian to translate.</param>
    /// <returns>String in Translit.</returns>
    public static string ToTranslit(this string russian)
    {
        var builder = new StringBuilder(russian);

        foreach (var letter in letters)
        {
            builder.Replace(letter.Key, letter.Value);
        }

        return builder.ToString();
    }
}

public ActionResult Plain(string text)
{
   File(text.ToBytes(), "text/plain", "Текст.txt".ToTranslit());
}

Упрощение навигации по DOM

Хотелось бы затронуть тему правильной организации DOM, best practices, так сказать. Возможно немного пространно сформулировал, но смысл станет ясен после примера.

Пример. Форма ввода свойств некоторой сущности. Конкретнее: редактирование данных пользователя.

С чем столкнулся на практике:

<form action="#">
    <input id="UserId" type="hidden" />
    <div>
        <label>Имя:<input id="UserName" type="text" /></label>
    </div>
    <div>
        <label>Описание:<input id="UserDescription" type="text" /></label>
    </div>
</form>

Запрос с помощью jQuery выглядит следующим образом:

function GetUser() {
    return {
        id: $("#UserId").val(),
        name: $("#UserName").val(),
        description: $("#UserDescription").val()
    };
}

И казалось бы, все отлично. Если бы не:

• а если у нас несколько элементов управления для ввода данных о пользователях - конфликт идентификаторов (идентификатор должен быть уникален в пределах страницы)?
• а если наша сущность называется OurEntityWithVeryVeryReallyVeryLongName и имеет множество полей, представляете себе кошмар в виде id="OurEntityWithVeryVeryReallyVeryLongNameFieldWithLongName1" и тому подобное?

Что предлагаю:

<form class="User" action="#">
    <input class="Id" type="hidden" />
    <div>
        <label>Имя:<input class="Name" type="text" /></label>
    </div>
    <div>
        <label>Описание:<input class="Description" type="text" /></label>
    </div>
</form>

Теперь и запрос с помощью jQuery выглядит иначе:

function GetUser() {
    var user = $(".User");
    return {
        id: $(".Id", user).val(),
        name: $(".Name", user).val(),
        description: $(".Description", user).val()
    };
}

Как по мне, вполне приемлемо, и даже похоже на объектную нотацию ("User.Name").

Возможно где-то в Сети уже есть подобное или лучшее решение, как делают Про я не искал (зря? тогда жду комментариев), сразу решил поделиться пришедшей мыслью. На этом все. Удачной разработки!

jQuery: позиционирование элементов

Простая задача - разместить абсолютно позиционированный (в стиле определено: position: absolute) div под элементом ввода (input).

var input = $("input");
var offset = input.offset();

var x = offset.left;
var y = offset.top + input.height();

$("div").offset({
    left: x,
    top: y
});

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

Окончательное решение далее.

var input = $("input");
var offset = input.offset();

var x = offset.left;
var y = offset.top + input.height() + $(window).scrollTop();

$("div").offset({
    left: x,
    top: y
});

JavaScript: Object Oriented or Not?

Все началось с написания клиентских скриптов для существующего веб-приложения с массивным использованием jQuery и асинхронных запросов (aka ajax).

Используется процедурный подход. Я же за ООП, как за средство эффективного снижения сложности.

Ближе к делу.

Поиск по данной теме сразу же привел меня на сайт Дугласа Крокфорда (см. раздел по JavaScript). Не буду пересказывать - очень советую прочесть его статьи по JavaScript - лучшее что я читал за последнее время.

Теперь поделюсь примерами из собственного опыта.

Пространства имен - то, к чему я очень привык, разрабатывая на C++, и особенно на C#.

var Namespace1 = Namespace1 || {};
Namespace1.Namespace2 = Namespace1.Namespace2 || {};

Приватные поля - то, без чего вообще жить нельзя.

Namespace1.Namespace2.Cat = function (name_) {
    var name = name_;
    this.getName = function () {
        return name;
    };
};

Namespace1.Namespace2.Cat.prototype.Meow = function () {
    alert(this.getName() + " says: meow!");
};

Теперь, если выполнить код:

var cat = new Cat("Bluetooth");
cat.name = "WiFi";
cat.Meow();

То "кот промяукает": "Bluetooth says: meow!", но не "WiFi says: meow!".

На этом пока все, в продолжении обязательно расскажу как я реализую наследование.

Fluent NHibernate и in-memory SQLite база данных

Недавно пришлось писать юнит-тесты для подсистемы доступа к данным, использующей Fluent NHibernate. Для тестов было решено использовать in-memory базу данных SQLite.

Все бы хорошо, да вот проблема - при попытке сохранения данных (ISession.SaveOrUpdate) вылетает исключение "...no such table...". При этом использовалась утилита SchemaExport, так что с созданием таблиц все должно быть в порядке (т. е. это не этот случай).

Так в чем же дело, почему "...no such table..." при попытке "INSERT..."? Не буду много писать, лучше дам ссылку - тут и описание проблемы и одно из ее решений.

MSVS и не CrLf-окончание строки

Битые 11 минут сижу просматриваю чистейший участок кода на наличие синтаксических ошибок.

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

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

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

Расчет необходимой мощности блока питания ПК

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