Нет, я не собираюсь перечислять нововведения в новой версии ROR, это уже сделали другие, а я лишь представлю вам их наработки. Встречаем очередную бесплатную книгу по рельсам - “Ruby on Rails 2.1 - What’s new”. В ней, как можно догадаться из названия, описываются (главные?) нововведения в последней версии фреймворка.
Почитать о книге и скачать её можно здесь.
PS. Сам книгу посмотрел… Могу сказать, что тем, кто рельсами не занимается, она будет довольно непонятной. Прочтите что-нибудь другое, например, Agile Development With Rails.
Вышел второй релиз-кандидат Symfony 1.1. Улучшений немного, по сравнению с предыдущими бетами и rc, что, несомненно, радует - версия 1.1 становиться всё стабильнее и стабильнее - уже и релиз не за горами.
Тем временем Fabien (главный разработчик Symfony) разродился кучкой постов:
- Изменение структуры директорий в проектах на Symfony 1.1.
- Отсылка писем в Symfony 1.1 с помощью Swift Mailer. В версии 1.0 для этого использовался PHP Mailer, обернутый в симфониевский декоратор.
- Как создать оптимизированную под iPhone версию вашего сайта с помощью Symfony. За неприглядным (как по мне) названием лежит интересный рассказ о форматах представления и mime-type’ах. Советую почитать, очень интересно. Ах да, про iPhone всё-таки не забыли. :)
Сергей опубликовал замечательный пост про сервисы поиска программного кода. Если честно - я такие никогда в жизни не использовал, так что если начну - только благодаря этому посту.
После релиза jQuery 1.2.6 долгое время раздел Release Notes пустовал. Сегодня вот заметил, что его наконец заполнили.
Из улучшений:
- Глобальное ускорение
- работа с событиями ускорена более чем в два раза
- селекторы ускорены на 13%
- .offset() ускорен на 21%
- работа с CSS (.css()) ускорена на четверть
- Кое-что улучшено, кое-что добавлено, вроде в API ничего не изменено
Как сообщает нам наш официальный источник - вышел первый релиз-кандидат jQuery UI - набора виджетов и визуальных эффектов для известного в узких кругах JS-фреймворка jQuery.
Как утверждает источник, RC1 довольно стабилен, а точнее - это самая стабильная версия из тех, которые вообще выпускались. :) Так что - спешите обновляться.
Ах да, чуть не забыл - в некоторых местах поменялось API (в draggable и resizable модулях так точно поменялось), так что будьте всё же осторожны и предусмотрительны.
Авось, кто-то еще не догадался… :)
Самый простой способ использования своих скриптов совместно с Google AJAX Libraries API:
google.load("jquery", "1");
google.setOnLoadCallback(function() {
$('<script type="text/javascript" src="_url_вашего_скрипта_"></script>').appendTo('head');
$('<script type="text/javascript" src="_url_вашего_другого_скрипта_"></script>').appendTo('head');
// ...
});
Аналогичным образом подключаются, например, плагины для jQuery.
Цель статьи - показать, что из себя представляет “ненавязчивый JavaScript”, для чего он нужен, и чем он лучше “навязчивого” JavaScript. В рунете я подобных статей не встречал (может они и есть, но мне на глаза не попадались и немного погуглив, я тоже ничего не нашел), а как показывает практика - очень многие не знают, что это такое и как этим пользоваться.
Что такое Unobtrusive JavaScript
Unobtrusive JavaScript - это техника программирования на языке JavaScript, которая состоит из следующих принципов:
- разделения структуры (HTML) / оформления (CSS) и поведения (JavaScript)
- использование JavaScript для повышения удобства использования уже рабочего приложения
- применения техники Graceful degradation - если браузер не поддерживает те или иные функции, которые мы добавляем в приложение с помощью JavaScript - приложение всё равно остается рабочим
Зачем?
Это удобно, это практично, это легко реализуемо и это помогает Вам увеличить аудиторию вашего сайта за счет пользователей, пользующихся старыми браузерами, отключающими JavaScript, пользователей, которые пользуются интернетом с мобильных устройств.
Как?
Легче всего показать это на примере. За ним далеко идти не нужно - возьмем всеми любимый Хабрахабр:
<div class="text_comments">
<div class="comment_item" style="margin-left: 0px;">
<div class="service_text_comments_holder">
<a href="http://fxposter.habrahabr.ru/" class="comments_nickname">fxposter</a>
...
</div>
<div class="comment_text">...</div>
<div class="comments_reply">
<div class="reply_word_holder" id="reply_link866650">(<a href="javascript:saw(866650);">ответить</a>)</div>
<div style="display: none" id="reply866650">
<!-- форма отправки комментария -->
</div>
</div>
</div>
</div>
Это код комментариев, которые показываются на страничке о посте. Для наглядности ненужные фрагменты были убраны.
Что плохо в этом фрагменте кода?
- JavaScript идет вперемешку с HTML (
<a href="javascript:saw(866650);">ответить</a>) - У людей с отключенным JavaScript’ом ответить на комментарий не получится в принципе
Как его можно улучшить?
- Вынести “навешивание” событий в отдельный файл
- Сделать так, чтобы при отключенном JavaScript’е пользователь перебрасывался на отдельную страницу, где бы он мог ответить на выбранный комментарий
Сказано - сделано. Преобразуем HTML к следующему виду:
<div class="text_comments">
<div class="comment_item" style="margin-left: 0px;">
<div class="service_text_comments_holder">
<a href="http://fxposter.habrahabr.ru/" class="comments_nickname">fxposter</a>
...
</div>
<div class="comment_text">...</div>
<div class="comments_reply">
<div class="reply_word_holder" id="reply_link866650">(<a href="reply.php?comment_id=866650" class="show_reply_form" id="show_reply_form_866650">ответить</a>)</div>
<div style="display: none" id="reply866650">
<!-- форма отправки комментария -->
</div>
</div>
</div>
</div>
Как видите - я изменил тег <a> (присвоил ему “нормальный” href, добавил id и class). Теперь при нажатии на ссылку “ответить” пользователя будет перебрасывать на страницу ответа на выбранный вопрос. Этим я выполнил второй пункт в списке улучшений. Теперь давайте взглянем на первый пункт: для того, чтобы у пользователей, у которых включен JavaScript вместо редиректа выполнялось открытие формы под самим комментарием мне нужно выбрать все элементы с классом “show_reply_form” и каждому из них назначить на событие onclick функцию, которая бы “открывала” соответствующую форму.
Напишем соответствующую функцию:
function showForm(event) {
var id = parseInt(this.id.replace('show_reply_form_', ''));
saw(id);
return false;
}
Она берет this.id (т.е. id текущего обьекта), убирает из него “фразу” “show_reply_form_“, тем самым получая номер элемента, который нам нужно открыть и вызывает функцию saw, которая присутствовала изначально в HTML-коде. Для того, чтобы не произошел редирект после клика на ссылку - функция возвращает false.
Осталось только связать эту функцию с нашими ссылками.
В jQuery это делается так:
$('.show_reply_form').click(showForm);
В PrototypeJS - так:
$$('.show_reply_form').each(function(element) {
element.onclick = showForm;
});
После присвоения нашей функции элементу - this.id станет относится к id этого элемента (да, это “магия JavaScript” :) ).
Весь JavaScript-код теперь можно вынести в отдельный файл:
function showForm(event) {
var id = parseInt(this.id.replace('show_reply_form_', ''));
saw(id);
return false;
}
window.onload = function(event) {
$$('.show_reply_form').each(function(element) {
element.onclick = showForm;
});
}
Здесь мы вызываем “связывание” наших ссылок с функцией показа формы при событии window.onload (при загрузке страницы).
Таким образом я выполнил и первый пункт в списке улучшений.
Выводы
На мой взгляд, такое использование JavaScript, а именно - вынос всех функций на JS в отдельный файл и связывание этих функций с элементами страницы с помощью различных событий (здесь мы видели события window.onload и element.onclick) - это на данный момент - единственно правильное использование JavaScript.
Дерзайте, господа. :)
PS. Я прекрасно знаю, что можно использовать событие не window.onload, а DOMContentLoaded. Но я считаю, что для примера понятнее будет всё же использование window.onload.
Столкнулся с багом в WordPress’е при выводе постов, а точнее в “применении” к ним “типографики”:
Как видите, кавычки в некоторых словах расставлены абсолютно не так, как нужно. В поисках решения проблемы обнаружил следующее - в WordPress’е на каждый блок выходных данных, будь то заголовок, сам пост, его комментарии или что-либо еще, навешиваются фильтры, которые определенным образом изменяют блок - убирают теги, заменяют одни символы на другие и т. д.
В данном случае меня интересовал блок the_content (в данном случае понятие “блок” можно интерпретировать как “функция WP, которая возвращает некий контент”), который выводит содержимое поста. В файле wp-includes/default-filters.php можно увидеть, какие фильтры применяются к этому блоку:
add_filter('the_content', 'wptexturize');
add_filter('the_content', 'convert_smilies');
add_filter('the_content', 'convert_chars');
add_filter('the_content', 'wpautop');
add_filter('the_content', 'prepend_attachment');
Методом проб и ошибок было установлено, что найденный мной баг “создает” фильтр wptexturize (в WP “фильтр” - это функция, которая принимает 1 аргумент - входящий текст, и возвращает обработанный текст). Функция нашлась в файле wp-includes/formatting.php. Она выполняет “типографскую” работу, при этом пропуская всё, что находится между тегами pre, code, kbd, style и script. В теории… На практике - нихрена она не пропускает, если внутри одного из этих тегов будет какой-либо другой тег (что, в принципе, возможно, но встречается редко, а случай pre > code система хавает на ура), либо если внутри какого-нибудь из этих тегов встретится \[.*\] - вот такой кусок (у меня этим куском был ['comment_post_ID'], например). Почему так - не могу знать (мне вообще непонятно зачем наряду с тегами <.*> рассматривать еще и \[.*\]), но факт остается фактом. Улучшенная версия этого файла находится здесь (у меня WP 2.5.1, если что).







Последние комментарии