Продолжаем цикл статей на тему построения сайтов (веб-приложений) ориентируясь на максимальное применение AJAX технологии. Зачастую, при работе сайтов и приложений использующих AHAH требуется вместе с подгружаемым HTML контентом догружать файлы скриптов, которые не использовались ранее на страницах сайта. Одним из моментов обработки догружаемого AJAX-ом контента является выделение из получаемого контента файлов скриптов, с последующим их применением к текущему документу (DOM). Благо, на данный момент практически все основные библиотеки умеют это делать. Однако, если копнуть глубже в реализацию процесса обработки догружаемых скриптов, то текущая ситуация совсем «не радужная». Не все хорошо известные библиотеки умеют это делать хорошо, а тем более оптимально. Давайте рассмотрим указанный процесс изнутри, разберем существующие проблемы и узнаем пути их решения.

Вторая версия статьи, расширенная и дополненая.

Большая часть готовилась для моего выступления на «РИТ: Клиентские технологии», куда я, к сожалению, не доехал.

 



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

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

Многим JavaScript-разработчикам приходилось сталкиваться с объектами, перечисленными в заголовке, например, при решении следующих задач:
— создание визуальных редакторов (wysiwyg),
— поиск в окне браузера,
— выставление BB-кода,
и т.д.

В этой статье автором предпринята попытка собрать перевод документации об этих объектах в одном месте + написать небольшие сопроводительные примеры. Перевод вольный, не дословный, так что если встретите неточность или корявую формулировку — пишите в комментариях.

В целом пост носит справочный характер, и, надеюсь, кому-то упростит разработку.

Алгоритм возможно не новый, и не является идеалом, но, на удивление, работает. Никаких графов и корелляции.

Для начала, стоит отметить, что сравнение очень приблизительно (по крайней мере, на данном этапе), временами две совершенно разные фотографии оказываются похожими процентов на 60%, так же не учитываются жесткие модификации (повороты, инверсия, обрезка) – для этого нужно доводить и доводить. Лично для меня самым главным оказались два параметра: скорость, независимость от разрешения изображения и возможность сравнивать «изображения» прямо в базе данных.

Последнее время оживилась публика с вопросом случайной выборки из таблицы. Решений по оптимизации полно, и нового сейчас я вам наверное ничего не покажу, просто напомню про основные методы оптимизации — упрощение запроса и индексацию. Без предисловий про фриленсеров, сразу к делу ;)

В этой статье рассмотривается валидация email изпользуя регулярные выражения. Все регэкспы выполняются с модификатором i, т.е. делают регистронезависимую проверку.

Очень простая, но полезная библиотека PHP_Exceptionizer позволяет преобразовывать нотисы (E_NOTICE), предупреждения (E_WARNING) и т. д. в исключения PHP.

// Где-то в начальном коде инициализации скрипта.
error_reporting(E_ALL);
if (<is debug mode active>) {
    $exceptionizer = new PHP_Exceptionizer(E_ALL);
    // И оставьте эту переменную, чтобы она не удалялась до окончания 
    // скрипта. Удаление переменной вызовет отключение PHP_Exceptionizer.
}
...
// Далее можно ловить нотисы как исключения:
try {
    echo $undefinedVariable;
} catch (E_NOTICE $e) {
    echo "Notice raised: " . $e->getMessage();
}
...
// Если вы ловите E_WARNING, то поймаете и E_NOTICE тоже:
try {
    echo $undefinedVariable;
} catch (E_WARNING $e) {
    echo "Warning or better raised: " . $e->getMessage();
}
...
// А можно и не ловить, тогда нотис вызовет завершение программы.
echo $undefinedVariable;

Web Optimizer (Веб Оптимизатор) — приложение, автоматизирующее все действия по клиентской оптимизации для произвольного сайта. На данный момент оно существует в виде отдельного приложения (которое нужно самостоятельно установить на сайт). В качестве базы для Web Optimizer использовался PHP Speedy.

Подробное руководство по установке.
Загрузить версию 0.3.

Проблема: при переводе приложений на другие языки (чаще мы сталкиваемся с русификацией англоязычных продуктов) чаще всего страдает поддержка множественных форм чисел. Например, «1 заметка, 2 заметки, 5 заметки» или якобы универсальное «1 file(s)» и т.д. Дело в том, что во всех языках программирования обычно дело не идет дальше варианта sprintf() или какого-то шаблонизатора, а поддержку множественных форм надо каждый раз программировать ручками: если N = 1, то «1 заметка», иначе «N заметок». А делать это каждый раз лениво. Эту задачу частично решает фреймворк gettext, где есть понятие нескольких вариантов локализованной строки, но это не сильно облегчает жизнь, ибо в одной строке, показываемой пользователю, может быть несколько частей, зависящих от чисел («Найдено 23 файла в 3 папках»), а значит куски строк надо потом все равно склеивать между собой.

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

Как известно, в разных языках разное количество множественных форм числа. В английском их два («1 file», «many files»). В русском — три («1 файл», «2 файла», «много файлов»). В арабском их вообще, как говорит нам Pootle, аж 6 штук. Поэтому нам нужно иметь возможность задавать прямо в строке набор из нескольких подстрок и параметр, от которого зависит выбор этих подстрок.

Предлагаемый формат подстроки с множественными вариантами:
{%COUNTER%|FORM0|FORM1|FORM2[|FORM3][|FORM4][|...]}

где
%COUNTER% — это некое имя переменной, которое может иметь значения [0,1,2,3,...]
FORM0 — это версия строки для значения COUNTER = 0 (это особый случай, обычно требующий отдельного сообщения)
FORM1, FORM2 и т.д. — это альтернативные варианты текста для каждой множественной формы данного языка; для английского это будет два варианта, для русского — три и т.д.

Пример на английском языке:
{%F%|No files|1 file|%F% files} found in {%D%|0 folders|1 folder|%D% folders}.

Это даст нам следующие конечные варианты строки на выходе при подстановке различных значений %F% и %D%:
%F% = 0, %D% = 1 => No files found in 1 folder.
%F% = 1, %D% = 2 => 1 file found in 2 folders.

Тот же пример строки, переведенной на русский:
{%F%|Не найдено файлов|1 файл найден|%F% файла найдено|%F% файлов найдено} в {%D%|0 папках|1 папке|%D% папках|%D% папках}.

Это даст нам следующие конечные варианты строки на выходе при подстановке различных значений %F% и %D%:
%F% = 0, %D% = 1 => Не найдено файлов в 1 папке.
%F% = 1, %D% = 2 => 1 файл найден в 2 папках.

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

Было бы здорово иметь реализацию подобного микроязыка на разных языках программирования.

Надеюсь, кому-нибудь идея пригодится.

UPD: Результат не заставил себя долго ждать: в данном топике хабраюзер webdew делится реализацией функции на C#, за что ему большое спасибо.