Эволюция Viewer: управление блоками, слияние и минимизация JS/CSS
На SVN работа над LS0.4 кипит, начну понемногу описывать нововведения. Итак, сегодня у нас на очереди модуль Viewer, который постепенно «обрастает» очень вкусными полезностями. В этот модуль добавлено:
1. Управление выводимыми на страницу js,css файлами.
2. Управление выводимыми на страницу блоками через конфигурацию.
Подробнее под катом.
Функционал по управлению js/css файлами состоит в:
1. Возможности задавать через конфигурацию совокупность выводимых файлов «по умолчанию», т.е. если ничего другого для страницы не указано.
Пример дефолтной конфигурации для css:
В отличие от моего модуля Loader, здесь решена проблема с IE-хаками. При указании параметра отображения файла
он будет выведен как
2. Возможность переопределять список js/css по правилам, привязанным к виду URL страницы. При этом можно добавлять новые файлы или удалять из списка дефолтные. Это достаточно полезно, так как далеко не все 18 js-скриптов и 6 css нужны на всех страницах проекта. А если вам нужно подключить новый js для нового модуля, то вы можете не «нагружать» им весь проект — а только те страницы, который реально в этом нуждаются.
Сейчас в конфигурации прописано только одно правило (для примера):
«По просьбам трудящихся» я буду понемногу накапливать список подобных правил в сборке, чтобы движек сразу после установки использовал минимально возможный набор js/css.
3. Добавить js/css файл теперь можно из кода Action`a. Для этого доступны четыре функции Viewer`a: AppendScript(), PrependScript(), AppendStyle(), PrependStyle().
4. Судя по комментариям к записи о Loader`e и личным письмам в мой ящик — это самое долгожданное: возможность сливать js/css файлы в один с одновременным уменьшением их объема.
Для минимизации js скриптов используется библиотека JSMin, для минимизации CSS — CSSTidy (для справки: именно эти библиотеки лежат в основе работы набирающего популярности Web Optimizator`a). Настройка степени сжатия и выполняемых при этом действий осуществляется через основную конфигурацию.
По умолчанию все подключенные файлы сливаются в один .js и один .css (это позволяет уменьшить число GET запросов при загрузке страницы в 12 раз). Отдельно выводятся только IE-хаки, которые подгружаются или нет «по желанию» браузера. Но в конфигурации можно разбивать файлы на блоки, каждый блок будет слит в отдельный файл.
Слитые и сжатые .js, .css кешируются в папке templates/cache/. При этом в css файлах автоматически перезаписываются относительные пути к ресурсам. Поэтому, уважаемые верстальщики, не волнуйтесь — вашей работе этот механизм никак не помешает :) Предусмотрен механизм «сброса» кеша при замене\внесении изменений в js или css файл. Также разработан cron-процесс для периодической «зачистки» cache-директории от старых js/css файлов.
Функционал по управлению блоками:
Теперь в конфигурации вы можете указывать какие блоки в каких action`ах и event`ах выводить.
Пример такой конфигурации (правило для отображения блоков в экшенах Index и Blog):
Event для конкретного Action можно задавать прямо или регулярным выражением, а можно вообще не задавать — тогда правило сработает для всех Event`ов указанного Action`a.
В приведенном примере:
— 'rule_index_blog' — название правила (осмысленные названия правил дают возможность переопределять их в коде при необходимости);
— 'index', 'blog' — названия экшенов для правила;
— 'index' => array('index') — название/я event`ов action`a Index;
— 'blocks' — массив блоков с указанием параметров добавления.
В добавлении блока теперь участвует дополнительный параметр — priority, который дает возможность управлять порядком вывода блоков.
На этом громкие сенсации во Viewer заканчиваются, комментарии, идеи, баг репорты и краш-тесты приветствуются.
Впереди еще рассказы о новом роутере, новых возможностях конфигурации, о модуле обработки изображений Image, обертке для Cron-процессов, отложенной отправке почты, о закрытых блогах, возможностях кастомизации модулей и сущностей, взаимной дружбе, блекджеке…
Как сказал бы сейчас Малахов: Не переключайте каналы.
1. Управление выводимыми на страницу js,css файлами.
2. Управление выводимыми на страницу блоками через конфигурацию.
Подробнее под катом.
Функционал по управлению js/css файлами состоит в:
1. Возможности задавать через конфигурацию совокупность выводимых файлов «по умолчанию», т.е. если ничего другого для страницы не указано.
Пример дефолтной конфигурации для css:
$config['head']['default']['css'] = array(
$config['path']['static']['skin']."/css/style.css?v=1",
$config['path']['static']['skin']."/css/Roar.css",
$config['path']['static']['skin']."/css/piechart.css",
$config['path']['static']['skin']."/css/Autocompleter.css",
$config['path']['static']['skin']."/css/prettify.css",
$config['path']['static']['skin']."/css/thickbox.css",
$config['path']['static']['skin']."/css/ie6.css?v=1"=>array('browser'=>'IE 6'),
$config['path']['static']['skin']."/css/ie7.css?v=1"=>array('browser'=>'gte IE 7'),
$config['path']['static']['skin']."/css/simple_comments.css"=>array('browser'=>'gt IE 6'),
);
В отличие от моего модуля Loader, здесь решена проблема с IE-хаками. При указании параметра отображения файла
'browser'=>'IE 6'
он будет выведен как
<!--[if IE 6]>.....<![endif]-->
2. Возможность переопределять список js/css по правилам, привязанным к виду URL страницы. При этом можно добавлять новые файлы или удалять из списка дефолтные. Это достаточно полезно, так как далеко не все 18 js-скриптов и 6 css нужны на всех страницах проекта. А если вам нужно подключить новый js для нового модуля, то вы можете не «нагружать» им весь проект — а только те страницы, который реально в этом нуждаются.
Сейчас в конфигурации прописано только одно правило (для примера):
$config['head']['rules']['page'] =array(
'path'=>$config['path']['root']['web'].'/page/',
'js' => array(
'exclude' => array(
$config['path']['static']['skin']."/js/vote.js",
$config['path']['static']['skin']."/js/favourites.js",
$config['path']['static']['skin']."/js/questions.js",
)
),
);
«По просьбам трудящихся» я буду понемногу накапливать список подобных правил в сборке, чтобы движек сразу после установки использовал минимально возможный набор js/css.
3. Добавить js/css файл теперь можно из кода Action`a. Для этого доступны четыре функции Viewer`a: AppendScript(), PrependScript(), AppendStyle(), PrependStyle().
4. Судя по комментариям к записи о Loader`e и личным письмам в мой ящик — это самое долгожданное: возможность сливать js/css файлы в один с одновременным уменьшением их объема.
Для минимизации js скриптов используется библиотека JSMin, для минимизации CSS — CSSTidy (для справки: именно эти библиотеки лежат в основе работы набирающего популярности Web Optimizator`a). Настройка степени сжатия и выполняемых при этом действий осуществляется через основную конфигурацию.
По умолчанию все подключенные файлы сливаются в один .js и один .css (это позволяет уменьшить число GET запросов при загрузке страницы в 12 раз). Отдельно выводятся только IE-хаки, которые подгружаются или нет «по желанию» браузера. Но в конфигурации можно разбивать файлы на блоки, каждый блок будет слит в отдельный файл.
Слитые и сжатые .js, .css кешируются в папке templates/cache/. При этом в css файлах автоматически перезаписываются относительные пути к ресурсам. Поэтому, уважаемые верстальщики, не волнуйтесь — вашей работе этот механизм никак не помешает :) Предусмотрен механизм «сброса» кеша при замене\внесении изменений в js или css файл. Также разработан cron-процесс для периодической «зачистки» cache-директории от старых js/css файлов.
Функционал по управлению блоками:
Теперь в конфигурации вы можете указывать какие блоки в каких action`ах и event`ах выводить.
Пример такой конфигурации (правило для отображения блоков в экшенах Index и Blog):
$config['block']['rule_index_blog'] = array(
'action' => array(
'index' => array('index'),
'blog',
),
'blocks' => array(
'right' => array('stream','tags','blogs'=>array('params'=>array(),'priority'=>1))
)
);
Event для конкретного Action можно задавать прямо или регулярным выражением, а можно вообще не задавать — тогда правило сработает для всех Event`ов указанного Action`a.
В приведенном примере:
— 'rule_index_blog' — название правила (осмысленные названия правил дают возможность переопределять их в коде при необходимости);
— 'index', 'blog' — названия экшенов для правила;
— 'index' => array('index') — название/я event`ов action`a Index;
— 'blocks' — массив блоков с указанием параметров добавления.
В добавлении блока теперь участвует дополнительный параметр — priority, который дает возможность управлять порядком вывода блоков.
На этом громкие сенсации во Viewer заканчиваются, комментарии, идеи, баг репорты и краш-тесты приветствуются.
Впереди еще рассказы о новом роутере, новых возможностях конфигурации, о модуле обработки изображений Image, обертке для Cron-процессов, отложенной отправке почты, о закрытых блогах, возможностях кастомизации модулей и сущностей, взаимной дружбе, блекджеке…
Как сказал бы сейчас Малахов: Не переключайте каналы.
68 комментариев
Когда ожидать релиз 0.4?
ДвижОк!
«Prepend». I don't know what «prepand» means.
А так изменения очень радуют.
:)
Вот это очень жду.
Тут все действительно от подхода сильно зависит.
В 0,31 с модулями получается какой-то монстр с горой яваскрипта и css)
Но видимо уже мало имеет смысла продолжать развитие моего хака действительно… :-)
Опять же из других отличий — я не стал бороться с кешированием всех лент и учетом кому и что показывать (так как по идее пользователь итак находясь в закрытом блоге получает оповещения и знает о происходящем). Надо посмотреть как вы это реализовали. :-)
Но вообще — это замечательно, что такая штука появилась родная. А я уж либо заброшу свое решение, либо разовью во что-то более функциональное :-)
В отображении записей появляется понятие Accessible блог (Открытые + Те, в которых моя роль выше нулевой). Ньансов, тонкостей и хитростей много. Чего только стоит перевод ранее открытого блога в закрытый :)
У них есть какое-то глобальное определение? Или это всего лишь цифра, которая фигурирует в связи пользователь-блог?
Создания новых ролей «правильнее» всего (с архитектурной точки зрения) организовывать с помощью подмены LsBlog кастомным, унаследованным от исходного.
Разбирайтесь :)
но волнут 2 других вопрса. Как будет с производительностью? Ведь всякое усложнение кода ведет за собой дополнительные затраты процессорного времени. И второй вопрос, нунжо будет что-то придумаь с упрощенным переездом на новую версию движка. Просто у многих польхователей стоит куча дополнительных модулей и просто хаов.
2) Если посмотреть SVN то очевидно что нереально перевести 0.3.1 с модулями (неизвестно какими) на 0.4 автоматической операцией… Только ручками… пилить и строгать… пилить и строгать… пилить и строгать
Вообще Пока не выйдет версии 1.0 не стоит ждать чего-то автоматического… Ведь движок ещё только формируется.
Чёт я совсем загнался — отвечаю на вопросы заданные создателям движка ))
/templates/skin/new/actions/ActionPage/page.tpl
вот эту строку уберите.
2) Правила не нужно использовать, они используются Viewer`ом автоматически.
3) Приведенные в примере строки уже добавлены в конфиг ядра.
Вот есть правило для page
А как мне добавить сюда еще правило для people и profile к примеру, хочу разные наборы JS и CSS для этих модулей?
$config['head']['rules']['page'] — у нас массив как я понял только для одного правила. Если следом за ним написать еще раз $config['head']['rules']['page'] и в нем другое правило для другого пути, то предыдущее правило затрется новым.
AppendStyle() и PrependStyle() не проверял
ИМХО: как то мудрено вышло, разобраться бы…
P.S. Если я что-то пропустил при прочтении, то не пинайте.
2. Надо править config.php, а хотелось бы делать это динамически из экшена.