CRL
Новичок
И снова шаблонизатор.
Проектирую шаблонизатор.
Общее описание:
===============
1) Шаблон пассивен
2) Весь механизм визуального отображения разделен на основной шаблон и шаблоны модулей
2) Основной шаблон имеет в основе XHTML:
Пример:
=======
Вызов модуля осуществляется через тег <module ... /> с обязательным атрибутом name.
3) Шаблоны модулей имеют в основе XHTML с плейсхолдерами
Например:
=========
News.xml
4) Модель - это класс, методы которого соответствуют модулям основного шаблона.
5) Контроллер - класс-потомок Модели; в нем описан парсер шаблонов, работа с файлом конфигурации и вызов механизма отражения.
Предполагаемый принцип работы:
==============================
1) Контроллер загружает XHTML общего шаблона и находит в нем все теги <module ... /> (используется DOM).
2) Контроллер создает отражение самого себя и получает доступ к методам родителя - Модели.
3) Контроллер ищет среди доступных методов Модели метод, имеющий название, соответствующее значению атрибута name текущего обрабатываемого тега <module ... />
4) Если метод обнаружен, создается его отражение и определяются параметры, которые он принимает. Если параметры, переданные через <module ... /> соответствуют или не противоречат параметрам модуля, производится вызов этого метода-модуля с передаными параметрами, в противном случае генерируется соответствующее сообщение об ошибке. При выполнении метода-модуля, он подгружает соответствующий ему шаблон, заменяет плейсхолдеры на необходимые фактические значения, и на основании этого генерируется результат.
5) Результатом работы модуля или сообщением об ошибке Контроллер заменяет соответствующий тег <module ... /> в dom-документе, созданном из основного шаблона.
6) Вывод документа в браузер.
Теперь, собственно, к вопросам:
===============================
1) В данном случае, шаблоны не содержат никаких "программерских" конструкций и кажутся мне достаточно очевидными для верстальщика. Так же достаточно очевидным кажется мне и взаимодействие между программистом и верстальщиком - первый просто передает второму описание API: формат вызова модуля в общем виде, перечень модулей и принимаемых ими параметров. Однако, как же упростить работу самим програмистам, если предположить, что над проектом работает несколько разработчиков? Модули-методы Модели не являются атомарными, их нельзя рассматривать отдельно от Модели - это следует хотя бы из того, что методы Модели могут обращаться к свойствам Модели или взаимодействовать друг с другом, потому каждый разработчик должен иметь актуальную копию класса Модели, что не есть гут. И как это побороть, я пока не знаю.
2) Не могу придумать, как добиться кеширования документов: так как система не транслирует шаблон в промежуточный код, имеющий РНР-вставки, а сразу вставляет в него результат своей работы, сохранять такие страницы нельзя, что тоже страшный трабл.
3) Вполне вероятно, что сам принцип или его предполагаемая реализация имеют еще какие-то изъяны, которых я не вижу, поэтому очень надеюсь на адекватную критику.
Проектирую шаблонизатор.
Общее описание:
===============
1) Шаблон пассивен
2) Весь механизм визуального отображения разделен на основной шаблон и шаблоны модулей
2) Основной шаблон имеет в основе XHTML:
Пример:
=======
PHP:
<?xml version="1.0" encoding="UTF-8"?>
<html>
<head>
<title>
<module name="title" out="page_id" />
</title>
<link rel="stylesheet" type="text/css" href="/styles/main.css">
</head>
<body>
<table>
<tr>
<td>
<module name="news" count="10" title="on" />
</td>
<td>
<module name="content" />
</td>
</tr>
</table>
</body>
</html>3) Шаблоны модулей имеют в основе XHTML с плейсхолдерами
Например:
=========
News.xml
PHP:
<div id="task_name">
[+task_name+]
</div>
<hr />
<br />
<div id="news_title">
[+news_title+]
</div>
<div id="news_body">
[+news_body+]
</div>5) Контроллер - класс-потомок Модели; в нем описан парсер шаблонов, работа с файлом конфигурации и вызов механизма отражения.
Предполагаемый принцип работы:
==============================
1) Контроллер загружает XHTML общего шаблона и находит в нем все теги <module ... /> (используется DOM).
2) Контроллер создает отражение самого себя и получает доступ к методам родителя - Модели.
3) Контроллер ищет среди доступных методов Модели метод, имеющий название, соответствующее значению атрибута name текущего обрабатываемого тега <module ... />
4) Если метод обнаружен, создается его отражение и определяются параметры, которые он принимает. Если параметры, переданные через <module ... /> соответствуют или не противоречат параметрам модуля, производится вызов этого метода-модуля с передаными параметрами, в противном случае генерируется соответствующее сообщение об ошибке. При выполнении метода-модуля, он подгружает соответствующий ему шаблон, заменяет плейсхолдеры на необходимые фактические значения, и на основании этого генерируется результат.
5) Результатом работы модуля или сообщением об ошибке Контроллер заменяет соответствующий тег <module ... /> в dom-документе, созданном из основного шаблона.
6) Вывод документа в браузер.
Теперь, собственно, к вопросам:
===============================
1) В данном случае, шаблоны не содержат никаких "программерских" конструкций и кажутся мне достаточно очевидными для верстальщика. Так же достаточно очевидным кажется мне и взаимодействие между программистом и верстальщиком - первый просто передает второму описание API: формат вызова модуля в общем виде, перечень модулей и принимаемых ими параметров. Однако, как же упростить работу самим програмистам, если предположить, что над проектом работает несколько разработчиков? Модули-методы Модели не являются атомарными, их нельзя рассматривать отдельно от Модели - это следует хотя бы из того, что методы Модели могут обращаться к свойствам Модели или взаимодействовать друг с другом, потому каждый разработчик должен иметь актуальную копию класса Модели, что не есть гут. И как это побороть, я пока не знаю.
2) Не могу придумать, как добиться кеширования документов: так как система не транслирует шаблон в промежуточный код, имеющий РНР-вставки, а сразу вставляет в него результат своей работы, сохранять такие страницы нельзя, что тоже страшный трабл.
3) Вполне вероятно, что сам принцип или его предполагаемая реализация имеют еще какие-то изъяны, которых я не вижу, поэтому очень надеюсь на адекватную критику.
