Рефакторинг рендереров/шаблонизаторов. Введение версионности API?

 
+
-
edit
 

Balancer

администратор
★★★★★
Наконец, взялся за давноооо назревший рефакторинг рендерера (как же это по-русски-то сказать?).

Напомню, как выглядит этот механизм сейчас.

Каждый объект может иметь класс, занимающийся отображением этого объекта пользователю. Класс-рендер. При выводе объекта дёргается его метод render()
, который и возвращает контент. Бинарное содержимое картинки, XML RSS-фида или HTML страницы.

Страницы состоят из двух компонентов:
  1. Глобальный шаблон (шапка+подвал+etc - общее оформление)
  2. Локальный шаблон (собственно, тело страницы)


Всё бы хорошо, но реально рефакторинг проводился достаточно поздно, когда объекты уже рендерили сами себя, так что сейчас присутствует такая логика: если у объекта есть рендер, то вызывается он. Нет - вызывается стандартный, hardcoded-рендер старого типа (на Smarty, интегрированном в систему). Плюс несколько раз менялась терминология методов, занимающихся подготовкой данных для насыщения шаблонов. Из-за обратной совместимости эти имена поддерживаются во всех вариантах (например, local_template_data_set()
, local_data
и др.)

Сейчас назрел рефакторинг и окончательная чистка "встроенного рендера". Логика будет (и местами уже есть) такая:

- Каждый объект имеет строковый метод render_engine()
, возвращающий имя класса отображения. Это уже есть и вовсю импользуется для вывода не-HTML объектов. Нужно только доработать механизм статического кеширования. Сейчас он hardcoded в базовом коде объекта, но им, наверное, должен заниматься рендер. Или даже совсем отдельный класс. Вопрос только тогда, откуда дёргать этот класс, из базового класса или рендера. Наверное, лучше из рендера. Базовый класс не должен заботиться о том, откуда рендер берёт контент.

- В случае страниц (текущее имя класса рендера bors_render_page
, вот тут оканчивается уже имеющееся решение и начинаются текущие эксперименты) рендер (кстати, как правильно-то, render или renderer? :)) будет дёргать два класса, занимающихся насыщением шаблонов. Один для шаблона всей страницы (имя метода, возвращающего класс: page_template_engine()
), другой - для тела страницы (body_template_engine
). Шаблонизатор может быть один и на то, и на другое. Собственно, шаблонизатор получает шаблон, данные для его насыщения и возвращает HTML-код.

- Шаблонизаторы организуют новую сущность. Например, class bors_templates_twig
. Подготовкой данных для них занимается тот, кто их дёргает (в данном случае - bors_render_page
).

Вот с подготовкой данных назревает рефакторинг, на котором я, наверное, решусь поломать обратную совместимость. Сейчас всё просто:

- Есть методы, которые возвращают данные для шаблона: local_data()
для тела страницы (устаревшее название local_template_data_set()
) и global_data()
для всей страницы. Есть методы, указывающие список методов класса, значения которых нужно поместить в шаблон: template_vars()
и template_local_vars()
. Про вторые не думал, но у первых явно неудачное название. Думаю, лучше именовать их page_data()
и body_data()
. Кроме того, сейчас, при наследовании, если нужны данные родителя, каждый метод сам должен дёргать метод родителя и делать array_merge() для результатов. Но это можно сделать и из вызывающего метода. Пройти по всей иерархии и объединить результаты.

Очередное переименование + введение автоматической иерархии вводит очередную сущность в наполнении данных. Думаю, пора отряхнуть прах обратной совместимости и наших кроссовок :) Совершенно несложно сделать массовое переименование метода по всему проекту и выкидыванием вызовов метода-родителя. Но это приводит нас к путанице по уже завершённым проектам, если потребуется их обновлять. Можно помнить и не помнить, что и где уже изменено.

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

Посему пока текущему состоянию API в репозитории присваивается версия 0.1. Как только проведу рефакторинг (пусть даже пока и с поддержкой обратной совместимости) методов рендеринга - это будет началом версии 0.2 :)
 

в начало страницы | новое
 
Поиск
Настройки
Твиттер сайта
Статистика
Рейтинг@Mail.ru