уже намного лучше. Не буду говорить что мой метод элегантнее (это не так), но все же я пришел к такому: PHP: /* файл page.php */ <?php class NewsPage extends Page { function pageMain() { $this->wrapper->add('title', new TitleBlock('Последние новости')); $this->wrapper->add('content', $this->blockLastNews()); } function pageList() { $this->wrapper->add('title', new TitleBlock('Все новости')); $this->wrapper->add('content', $this->blockListNews()); } function blockLastNews() { $news = News::getLast(5); return $this->getBlockNews($news); } function blockListNews() { return $this->getBlockNews( News::getList() ); } function getBlockNews(News $news) { $blocks = array(); foreach ($news as $cnews) { $block = new NewsBlock(); $block->wrapper->add('date', $cnews->date); $block->wrapper->add('text', $cnews->text); $blocks[] = $block; } return $blocks; } } ?> /* файл layot.tpl */ <html> bla-bla-bla <?=$this->layot('title')?> bla-bla-bla <?=$this->layot('content')?> </html> /* файл news.tpl */ <div> Дата: <?=$this->layot('date')?> Текст: <?=$this->layot('text')?> </div>
Посмотрел. Вникать сейчас не могу (заставляют работать), одно замечание: никак не предусмотрено, что сайт может иметь несколько языковых версий.
А не в ущерб ли гибкости? P.S. Мне проще, когда всё в одном файе. Не надо метаться между шаблоном и классом.
tmanager, пожалуйста, не забывайте о PHP: <?php ?> А то много букв, без подсветки неудобно читать... А вообще несмотря на то что скодированно ИМХО как-то загадочно сама идея симпатична.
Нет, не в ущерб, использование классов мне наоборот, добавляет гибкости Я могу заменить любой блоковый класс любым наследником, при этом ничего больше менять не прийдется в существующем коде... Пример: PHP: <?php class TitleBlock extends Block { protected $content; function __construct( $content ) { // Объект класса Translate уже знает какой язык надо подставлять // Он оперирует с базой соответствий $this->content = Translate::instance()->get($content); } } ?>
у меня были такие гипердинамические шаблоны. Шаблонов, как таковых, не было, страница собиралась полностью из класса шаблонизатора, но были шаблоны каждого из модулей. Из плюсов это давало возможность, например, определить модулю свой CSS и JS файл, и вообще повлиять на сборку страницы не вводя костылей в виде дополнительных парсингов и разборов уже задействованных шаблонов. От идеи позже отказался, ибо как сказал бы Цезарь, est rerum omnium magister usus (Опыт всему учитель).
А разве с шаблонами нельзя реализовать это? шапка.tpl: Код (Text): <html> <head> <title>{$title}</title> <link href="template/templates/main.css" rel="stylesheet" type="text/css" /> {$style} {$meta} {$js} <script language="JavaScript" src="template/templates/menu.js"></script> </head> <body> модуль.tpl: Код (Text): {include file="шапка.tpl" title="Регистрация" js="<script language="JavaScript" src="template/templates/registration.js"></script>" style="<link href="template/templates/forms.css" rel="stylesheet" type="text/css" />" } //Контент шаблона. Смарти невероятно гибок. Я еще не нашел ничего такого, чегобы нельзя было в нём реализовать.
Я разве где то сказал, что это реализовать нельзя? Я рассказал, чем я руководствовался, не более того.
Горбунов Олег Просто я понял это как плюсик в сторону чудосистемы в сравнении с шаблонизатором. Кстати, ни 1 такого плюсика (преимущества) так и не было озвучено. И мне на ум не приходит ни одного. А преимуществ шаблононизатора - туева хуча и они все очень очевидны. Классный холивар
Плюсы небольшие есть в производительности. И кстати, остутствие центрального шаблона, кстати, ближе к идеологии разделения кода и оформления... Но это все не суть. Классические подходы вырабатывались умными людьми и немалое время... с опытом все все равно к ним приходят.
Тем что заголовки, JS и прочая - это не оформление Это же позволяет привязать хэдеры к формируемому документу более удобно т.е. обьект может отдавать хоть html, хоть rss, хоть xhtml... не привязываясь к шаблону, и это - правильно. Но это так, мои досужие домыслы. Я как нибудь, напишу про это статью.
Но ведь Вы сильно привязались к набору блоков. Разве нет? Откуда? И означает ли класс Translate, что языковые версии имеют одинаковое меню и одинаковое содержание? Если да -- тогда это не лучшее решение. Я считаю более правильным, когда каждая языковая версия имеет своё меню и содержание. Это просто более гармонирует с реальностью: скажем, зачем на туристическом сайте на русском языке рассказывать о России, а на аглийском -- объяснять порядок выезда россиян с детьми за границу?
Не все случаи сразу удалось предусмотреть. Появлялись форумы, галереи работ, статьи с возможностью поместить коментарий и -- и класс дописывался, сохраняя совместимость. Конечно, неплохо бы сейчас сесть и переписать класс page с учётом всего, что подсказывает опыт. Но время, время... Я ж сейчас пишу не сайты -- а программы автоматизации офиса на php/MySQL. Много работы. И нет времени отвлекаться на переделку того, что прекрасно работает.
Почему 20 лет? Не 22 года, не 14 лет? Классическим можно считать подход, существующий время, сравнимое с временем существования предмета его применения, т.е. отрасли в данный момент. Но поверьте, технологиям шаблонизации даже в информатике уже больше 20 лет.
Никто мне не мешает использовать RussianNewsPage и EnglishNewsPage, опять же, какую страницу выбрать разруливаться будет совершенно в другом месте
Примерно за 20 лет сменяется поколение специалистов. Если новое покоение подхватило подход -- можно что-то лепетать о классике. А отрасли никак не больше 10 лет. Термин "шаблонизация" слишком многозначен. Лучше говорить о пресловутом разделении HTML и программирования. Понятней, о чём речь идёт. Так вот это самое разделение прошло все стадии, что и любая новая идея. После эйфории -- ща всё поделим нафиг! -- подход занимает своё место среди остальных, которых сгоряча прокляли и объявили устаревшими. К примеру, ASP.NET, когда-то учинявший жесткое (правда, с лазейкой в виде ASP-шных тегов в странице дизайна) разделение дизайна и программирования, тихо похоронил эту жётскость, сделав разделение выбором разработчика.
Я писал. Неправильно разделять "ХТМЛ и программирование". Есть логика приложения, есть логика отображения. Вот их - надо разделять.
Дык а кто ж заголовки в шаблоны smarty пихает? Да и врядли, если контроллер предполагает, что отдаваться будет RSS, то view выдаст HTML...