пятница, 8 января 2010 г.

Template::Object (часть 2)

Продолжение рассказа о винтажном велосипеде. Начало тут.

Извините, что затянул с продолжением. Хотелось написать что-то грандиозное (а именно, CRUD), но из-за лени ничего не вышло (может, еще допишу). Так что, к сожалению, вторая часть Марлезонского балета будет немного смазанной :-( В этой статье я представляю обещанный пример классов, производных от Template::Object. Это три класса Template::Input, Template::Input::Text и Template::Input::Select. На этот раз никакого POD'а я не писал, так что пример использования смотрите по unit-тестам.

Сырцы качать отсюда.

Disclaimer. В предыдущей статье я упомянул, что CTPP является правильным шаблонизатором. К сожалению, вынужден опровергнуть своё заявление: в CTPP есть циклы и условные операторы. Моё заблуждение вызвано тем, что в одном хорошем докладе на Highload++ прозвучала фраза про CTPP и про способ его правильного использования в компании докладчика (жаль, не могу вспомнить, чей был доклад). То есть, они просто игнорировали все управляющие конструкции и использовали CTPP для описания голых блоков, а всю логику описывали в представлении.

Update: По наводке Анатолия Шарифулина был вычислен докладчик — Андрей Шетухин и компания — Рамблер (а именно, Рамблер-Почта).

Update #2. В общем, фишка Template::Object в том, что я бы по аналогии с ORM назвал object-template mapping. Создаешь шаблон-объект, инициализируешь его данными в том виде, в котором их тебе удобно передавать, и всё: объект сам знает, что с этими данными делать дальше.

Если необходимо повторное использование поведения объекта с разными шаблонами — это делается простой подменой шаблона, вся логика хранится отдельно. Через наследование и подмену шаблона легко реализуется сходное поведение объекта в различных условиях — скажем, представление одного объекта для пользователей с разным уровнем доступа.

Гибкость: из нескольких кубиков можно собрать кубик Рубика — композиция, из одного кубика можно сделать Borg cube — наследование.

Шаблоны — одно из тех мест, где код практически не используется повторно. Template::Object способен решить эту проблему.

А unit-тесты? Удобно ли вам писать unit-тесты на логику, зашитую в ваши шаблоны? Как часто вы забиваете на тесты по этой причине?

И да, мощность этого метода особенно заметна при использовании convention over configuration.

Posted by codeholic at 12:46
Labels: , , , ,

6 comments:

  1. Это был Андрей Шетухин, сейчас он руководитель Рамблер почты, почитай его ЖЖ. Я часто с ним спорю, но не сильно, т.к. бесполезно :)

    CTPP – правильный шаблонизатор для рампочты и подобных высоконагруженных проектов, для остальных – его использовать не стоит.
    ОтветитьУдалить
  2. У меня было подозрение, что это был кто-то из Рамблера, но не стал его озвучивать, побоявшись ненароком кого-нибудь обидеть :-)
    ОтветитьУдалить
  3. > для остальных – его использовать не стоит

    А Template::Object? ;-) С нетерпением жду бичевания.
    ОтветитьУдалить
  4. условия и циклы - это плохо?

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

    если я не прав, то как правильно?
    ОтветитьУдалить
  5. Условия и циклы в шаблонах - это плохо. Отдаем в вид массив данных - это хорошо (а еще лучше не массив, а любую произвольную структуру). Вот только шаблон != вид. Вид - это тоже определенная логика. И ее надо отделять от шаблона. Сколько раз в своей жизни в разных проектах можно писать одну и ту же логику "зебры"? Не лучше ль один раз ее описать и потом уже никогда больше к ней не возвращаться? Ладно, зебра. Это не очень сложно, можно и потрахаться. Но вот взять формы. На CPAN, конечно, есть бесчисленное множество разных генераторов форм. Но проблема в них в том, что они тупы - их не настроить под себя. Или динамический список страниц - его, конечно, писали под себя все ленивые программисты. Но приходилось ли вам для какого-нибудь проекта его "навернуть"? Чаще всего в таких случаях программисты делают copy-paste и дописывают нужный кусок. А copy-paste рождает PHP (в плохом смысле этого слова).
    ОтветитьУдалить
  6. Я понимаю, что это выглядит как патологический идеализм. Но, возможно, если эту идею развить, она уже не покажется такой патологически идеалистичной.
    ОтветитьУдалить

Подписаться на: Комментарии к сообщению (Atom)