[PHPCONF 2009] Еще один великолепный миф или абстракция в шаблонах представления
Еще один великолепный миф или абстракция в шаблонах представления
Полагаю, любой из нас желает, чтобы веб-проекты были максимально легкими в обслуживании, целостными, стабильными, масштабируемыми и нетребовательными к ресурсам. При этом мы хотим многомиллионную аудиторию пользователей и обогощенные интерфейсы пользователей. Одно из узких мест на этом пути - стыковка уровня представления данных и уровня сервисов. Когда на руках сотни килобайт xHTML статического прототипа и набор Flash/Flex/Silverlight приложений, жаждущих общения с серверной стороной, на ум приходят множество решений. Наиболее популярные из них – непосредственное использование PHP вьюверов и хелперов в шаблонах представления или же применение различных шаблонизаторов аля Smarty. В первом случае все замечтально относительно повторного использования, доступной гибкости в разработке и производительность на высоте. Однако не хватает абстракции – как бы замечательно не был спроектирован код шаблонов, все же это читается тяжелее, чем нотации языков пользовательского интерфейса. В случае шаблонизаторов – не та гибкость, не та производительность, да и абстракция логики относительна. А что если взять все лучшее с обоих подходов?
Итак, правило 1: разработчик волен использовать любые элементы, чтобы передать логику интерфейса в XML. В дальнейшем эти элементы будут преобразованы в DIV или же указанный тег HTML.
Правило 2: Шаблон содержит исключительно логику интерфейса, вся декорация вынесена в CSS. Это так в идеальном мире, в реальности мы имеем блоки HTML, предназначенные для декорации. Используем атрибут theme для связи логического элемента шаблона с декоратором.
Правило 3: Приправим разметку MVC. Динамический код, такой как, скажем, списки будет сформирован моделью и декорирован посредством вьювера. Используем атрибут controller для запроса соответствующего контроллера. Очевидно тот же контроллер должен быть запрошен, когда приходит AJAX запрос на обновление данного списка. Однако, учитывая характер запроса, ответ будет автоматически завернут в JSON. При запросе из Flash контроллер ответит на XML.
Что еще? Давайте сделаем доступными в шаблоне переменные среды платформы {Page.Content1}. Добавим локализацию заголовков и условия для элементов. Теперь осталось только обрабатывать элемент include, где может быть запрошен шаблон, PHP или HTML.
Вуаля, новый язык разметки готов. Встречайте LML (Layout Markup Languge). Однако если речь о языке, то нужен парсер, а парсер - это всегда плохо. Давайте не интерпретировать, а компилировать в PHP. В результате разработчик работает с абстрактной структурой документа, что после компиляции напоминает стандартный layout Zend Framework.
Дмитрий Шейко
Ведущий веб-разработчик
CRYTEK GmbH
Еще один великолепный миф или абстракция в шаблонах представления
Полагаю, любой из нас желает, чтобы веб-проекты были максимально легкими в обслуживании, целостными, стабильными, масштабируемыми и нетребовательными к ресурсам. При этом мы хотим многомиллионную аудиторию пользователей и обогощенные интерфейсы пользователей. Одно из узких мест на этом пути - стыковка уровня представления данных и уровня сервисов. Когда на руках сотни килобайт xHTML статического прототипа и набор Flash/Flex/Silverlight приложений, жаждущих общения с серверной стороной, на ум приходят множество решений. Наиболее популярные из них – непосредственное использование PHP вьюверов и хелперов в шаблонах представления или же применение различных шаблонизаторов аля Smarty. В первом случае все замечтально относительно повторного использования, доступной гибкости в разработке и производительность на высоте. Однако не хватает абстракции – как бы замечательно не был спроектирован код шаблонов, все же это читается тяжелее, чем нотации языков пользовательского интерфейса. В случае шаблонизаторов – не та гибкость, не та производительность, да и абстракция логики относительна. А что если взять все лучшее с обоих подходов?
Итак, правило 1: разработчик волен использовать любые элементы, чтобы передать логику интерфейса в XML. В дальнейшем эти элементы будут преобразованы в DIV или же указанный тег HTML.
Правило 2: Шаблон содержит исключительно логику интерфейса, вся декорация вынесена в CSS. Это так в идеальном мире, в реальности мы имеем блоки HTML, предназначенные для декорации. Используем атрибут theme для связи логического элемента шаблона с декоратором.
Правило 3: Приправим разметку MVC. Динамический код, такой как, скажем, списки будет сформирован моделью и декорирован посредством вьювера. Используем атрибут controller для запроса соответствующего контроллера. Очевидно тот же контроллер должен быть запрошен, когда приходит AJAX запрос на обновление данного списка. Однако, учитывая характер запроса, ответ будет автоматически завернут в JSON. При запросе из Flash контроллер ответит на XML.
Что еще? Давайте сделаем доступными в шаблоне переменные среды платформы {Page.Content1}. Добавим локализацию заголовков и условия для элементов. Теперь осталось только обрабатывать элемент include, где может быть запрошен шаблон, PHP или HTML.
Вуаля, новый язык разметки готов. Встречайте LML (Layout Markup Languge). Однако если речь о языке, то нужен парсер, а парсер - это всегда плохо. Давайте не интерпретировать, а компилировать в PHP. В результате разработчик работает с абстрактной структурой документа, что после компиляции напоминает стандартный layout Zend Framework.
Дмитрий Шейко
Ведущий веб-разработчик
CRYTEK GmbH
синтаксис исходных шаблонов - по сути blitz-конструкции, завернутые в xml.