Balancer: Все сообщения за 19 Сентября 2014 года

Давно назревала необходимость капитально прогрепать/проредить админскую почту на gmail. Что-то под 20 тыс писем, из которых процентов 90 — однотипный мусор. Но средствами Гугла чистить вот это всё... Ящик же к себе утягивать тоже не хотелось.
И, вот, вчера я наткнулся на замечательную приблуду — isync. Эта фигня умеет синхронизировать локальный Maildir (из любого каталога, предварительно создав его, если нет) с любым IMAP. Т.е. что делаем: синхронизируемся с Gmail (локально появляется Maildir), грепаем/удаляем ручками мусор, синхронизируем ещё раз. Voila! Почта убивается и на Gmail. Десятками тысяч (только медленно).
Годится, понятное дело, это и для бэкапа.
Ещё вдобавок, наконец, посмотрел на mutt. Впечатлился. У меня явно TUI головного мозга, очень удобно в mutt разгребать Maildir'ы :)

---

---

// Транслировано с juick.com

•  инфо
•  инструменты
• Ответить на сообщение

•  инфо
•  инструменты
• Ответить на сообщение

•  инфо
•  инструменты
• Ответить на сообщение

Яндекс.Музыка круто обновилась. Раньше было так, баловство, сейчас внезапно превратилась в серьёзный инструмент. Есть рекомендации (хотя пока весьма слабо, но факт!), есть радио по жанрам (вот оно рулит), есть отличный мобильный клиент, платные услуги. Никуда не делись интеграция с ВКонтакте и скробблинг Last.Fm. Добавилась базовая интеграция с Facebook. В общем, второй день слушаю музыку только через них

•  8
•  инфо
•  инструменты
• Ответить на сообщение

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

У меня давний и многолетний ООП головного мозга и даже удивительно, что я до последнего оставлял отдельной процедурно-шаблонной сущностью темы и шаблоны фреймворка. С одной стороны это нормально, с другой — возникает лишняя сущность, появляются проблемы с модификацией без наследования, рождаются параллельные сущности.

Ну, например. Я хочу делать шаблон страницы на Bootstrap. Никаких проблем, в рамках нынешнего использования шаблонизаторов делаетя на 1-2-3. Что и делалось не раз. Но, опаньки. Многие элементы фреймворка, которые сами генерируют HTML заточены на упрощённый мой оригинальный шаблон. Для Bootstrap нужен другой код. На первый раз вводим ряд проверок (if(config('use_bootstrap')) { .. } else { .. } ). Где-то просто используются разные субшаблоны модулей ( page.tpl,  page.bootstrap.tpl). А потом разработчики убивают саму концепцию унификации фреймворков и выпускают несовместимый Bootstrap3. Приехали.

После долгого ломания головы родилась сущность layout. Это некий набор кирпичиков-шаблонов, характерный для каждого базового шаблона с его CSS и идеологией. Т.е., например, нужно модулю вывести таблицу на стандартном шаблоне, он скармливает данные layout-генератору (скажем, класс, bors_layout_legacy), который возвращает нужный HTML. Нужно использовать bootstrap — указываем, что HTML генерирует уже bors_layout_bootstrap и всё хорошо.

Отвлекусь по пути. Ещё появляется проблема названий. Традиционно у меня template указывает на движок шаблонизатора. Smarty, там, Twig или чистый PHP. Но также template — это шаблон всей HTML-страницы. Пока последние были «внеклассовыми», проблем не было. Сейчас появилась проблема. Шаблон страницы на bootstrap — bors_templates_bootstrap. Шаблонизатор Smarty — bors_templates_smarty. И сущности разные. Наверное, надо переименовывать шаблонизаторы из templates в templaters Благо, они напрямую за пределами ядра мало где используются и исправить будет не сложно.

И вот, я подхожу к задаче генерации общего шаблона.

Первая проблема — потенциальный конфликт класса общего шаблона страницы и внутренних шаблонов модулей и компонентов. Очевидно, что в общем случае нельзя иметь шаблон страницы на bootstrap3 и использовать внутри элементы с bootstrap2. Они не совместимы. Нужно прямо устранить возможность такого конфликта. Это значит, что layout модулей должен выбираться не самими модулями, а его должен указывать класс представления, для которого создаются модули. Класс представления тоже должен выбирать его не сам, а забирать из общего шаблона. Поменял для представления вид дизайна страниц — должна поменяться вся кухня генерации HTML.

Поэтому логика такая:
— Мы указываем в классе представления, каким общим шаблоном должен он выводиться. Например, var $template_class = 'bors_templates_bootstrap3';
— Метод $this->content(); каждого представления загружает из объекта этого шаблона-класса его дефолтовый layout, которым потом и пользуются модули и шаблонизаторы тела страницы.

...

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

•  инфо
•  инструменты
• Ответить на сообщение

А, вообще, с новым подходом сильно упрощается логика работы шаблонизаторов. Им больше не нужно искать шаблоны по десятку разных критериев. Один класс — один шаблон в строго фиксированном месте. Нужно перекрыть шаблон своим? Просто делаем класс-наследник. Всё. И производительность в очередной раз подрастёт, так как меньше потребуется сканирования по каталогам...

•  инфо
•  инструменты
• Ответить на сообщение

Может, и наборос. Проверить сейчас сложно.

•  3
•  инфо
•  инструменты
• Ответить на сообщение