Тюнниг php как шаблонизатора.

fixxxer · 18 Фев 2010

Автор оригинала: Wicked
fixxxer
я правильно понимаю, что вместо parent вставится текст оригинального блока, но с переопределенным блоком title (будет: "domain.com: Title of this page"), а за ним доставятся <link> и <style>?

ага

Crys · 18 Фев 2010

вот как такое на native php изобразить?

В одной известной CMS тот-же тайтл можно переопределять после того, как он "выводится".

Имею ввиду
<title><?=$APPLICATION->ShowTitle()?></title>

потом (в футере, в компоненте, где угодно...)
$APPLICATION->SetTitle("Новый заголовок страницы");

Wicked · 18 Фев 2010

fixxxer
понятно... ну конкретно таких красот не получится, да, но конкретно в этом случае я бы воспользовался щедротами фреймворка:

layout template:

PHP:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
    <?php include_http_metas() ?>
    <?php include_metas() ?>
    <title>domain.com: <?php if (!include_slot('title')): ?>default title<?php endif; ?></title>
    <?php echo get_stylesheets($sf_response); # "stylesheets: [style]" во view.yml приложения ?>
    <?php echo get_javascripts($sf_response); # "javascripts: [jquery.min.js, common]" во view.yml приложения ?>
</head>
<body>
    <?php echo $sf_content ?>

    <?php if (!include_slot('footer')): ?>
      <div class="footer">
       блаблабла
      </div>
    <?php endif; ?>
</body>
</html>

action template:

PHP:

<?php slot('title') ?>Title of this page<?php end_slot() ?>
<?php use_stylesheet('extra-for-this-page') # лучше - через view.yml модуля ?>
<?php use_javascript('extra-for-this-page') # лучше - через view.yml модуля ?>
............... <?php # <- sf, используя ob_, все остальное затолкает в $sf_content к моменту рендеринга layout'а ?>

вопросы?

HraKK · 18 Фев 2010

Не понимаю когда после компиляции/вставок вылазит хоть 1 символ HTML не описанный в контенте или шаблоне. Не знаю как вам, а мне шаблоны дают готовые полностью верстальщики, и какие-то нтмл сущности переносить в код - считаю медвежьей работой.

Ирокез
Ну я пошел чуть дальше, и расширил еще на пару сущностей.
Итого у меня есть такое понятие как Engine - например http, json, xml, socks.
И я передаю в объект Render( $View, $Engine )
Который уже передает на отображение в нужном мне формате - если http - то подключит шаблоны и отобразит, если в json - то в формате json( для аякс запросов, например), надо XML - получите, надо куда то по сокетам отправить ответ - получите и т.д.

Fortop

А где про такое прочитать можно? Я концепцию как-то уловил смутно, почему View должно еще что-то хранить и передавать?

Вью отвечает за отображение информации.
Итого стандартный вариант это когда контроллер или вью запрашивают данные и вставляют их во View->somedata = ...
А потом это все отображается. При этом этот вью может передаваться дальше в другие контроллеры, о чем я говорил.

Fortop · 18 Фев 2010

При этом этот вью может передаваться дальше в другие контроллеры

View то передаваться может. Но вот использовать его в качестве транспортного объекта для передачи данных между контроллерами - на мой взгляд как-то страно.

Именно поэтому я и хочу почитать что-нибудь об этом.

AmdY · 18 Фев 2010

Не знаю как вам, а мне шаблоны дают готовые полностью верстальщики, и какие-то нтмл сущности переносить в код - считаю медвежьей работой.

то есть, если тебе нужно в проекте вставить 20 таблиц с одинаковой разметкой, но разными данными ты делаешь это ручками вместо генерации? или каждый раз переновить разметку формы?
а если нужно поубирать двойные пробелы из шаблона, то каждый раз резать их регуляркой, ловя вывод в буфер?
представь хотя бы преимущества, которые даст прекомпиляция, которая заменит include на уже сам код из нужного шаблона.

Ирокез · 18 Фев 2010

Автор оригинала: HraKK
Ирокез
Ну я пошел чуть дальше, и расширил еще на пару сущностей.
Итого у меня есть ...

Ну у меня тоже не три компонента, а немного более

ну и мыж не описываем архитектуру и не спорим о ней.

Опять-же возвращаясь к шаблонизатору и отбрасывая кто кому дает сверстанные шаблоны, форматировать удобней там где выводишь. , возьмем к примеру текущее время time();
т.е. если тебе надо различные варианты времени для вывода то

PHP:

...
$tpl->t1 = date('Ymd',$view->ts);
$tpl->t2 = date('Ymd His',$view->ts);
...
и где-то в шаблоне

<?=$t1?> ... <?=$t2?>

неужто это нагляднее и проще нежели

...
где-то в шаблоне

<?=date('Ymd',$ts);?> ... <?=date('Ymd His',$ts);?>

HraKK · 18 Фев 2010

Ирокез
а чем это не PHP Native

PHP:

<?=date('Ymd',$ts);?> ... <?=date('Ymd His',$ts);?>

зачем

PHP:

$tpl->t1 = date('Ymd',$view->ts);
$tpl->t2 = date('Ymd His',$view->ts);

???

AmdY

то есть, если тебе нужно в проекте вставить 20 таблиц с одинаковой разметкой, но разными данными ты делаешь это ручками вместо генерации? или каждый раз переновить разметку формы?

почему? Я вынесу 1 таблицу в под шаблон и буду оттуда вставлять, либо просто <?php foreach(): ?>

а если нужно поубирать двойные пробелы из шаблона, то каждый раз резать их регуляркой, ловя вывод в буфер?

Ну это плюс, но кеш свободно решает и этот плюс.

представь хотя бы преимущества, которые даст прекомпиляция, которая заменит include на уже сам код из нужного шаблона.

Ога, а потом я нужный шаблон изменю, и что ? очищать весь кеш шаблонов?) Хотя можно конечно и очистить, не так часто меняются шаблоны, но имхо - опять же это работа кеша, а не шаблонов.

Fortop

Именно поэтому я и хочу почитать что-нибудь об этом.

Это лично мое представление о вью. Так как одну страницу могут генерировать несколько контроллеров, то логично что между ними связывающее звено будет View. Не, ну конечно можно несколько View композиционно отображать, но так как я сторонник активных шаблонов, то это выпадает из архитектуры.

Ну это опять же лично мое имхо, а как ты предлагаешь? С интересом послушаю (если что - без иронии).

Fortop · 18 Фев 2010

HraKK
Да никак я не предлагаю

опыта у меня может с год

Пока мне ближе идея с Layout (Two step view).
Передачу данных между контроллерами мне кажется лучше реализовывать через некий отдельный контейнер, не связанный с View. (в конечном счете может статься, что у нас результаты просто не должны никуда выводиться).
А View это конечный вывод и логика представления.

Но вот архитектурное решение активных шаблонов... ничего не могу сказать. Тот же ZF с которым я работал, настолько тяжел, что просто убивает любое решение в этом направлении.

Если есть легкий диспечер и контроллеры, то часть логики (что отображать) можно пернести в view.
Это(активные шаблоны) кстати, мне до боли напоминает подход визуального программирования. Когда накидали кнопок и форм, подцепили обработчики - и вуаля... работает (быстро, дешево и сердито).

HraKK · 18 Фев 2010

что у нас результаты просто не должны никуда выводиться).

У меня за вывод отвечает Engine
Я писал выше:

Итого у меня есть такое понятие как Engine - например http, json, xml, socks.
И я передаю в объект $Render->render( $View, $Engine )
Который уже передает на отображение в нужном мне формате - если http - то подключит шаблоны и отобразит, если в json - то в формате json( для аякс запросов, например), надо XML - получите, надо куда то по сокетам отправить ответ - получите и т.д.

Так же рендер отвечает за кеш и т.д.
По сути View у меня это только как ты и говоришь - контейнер с данными + содержащий метод обработки этих данных для вывода.

Это(активные шаблоны) кстати, мне до боли напоминает подход визуального программирования. Когда накидали кнопок и форм, подцепили обработчики - и вуаля... работает (быстро, дешево и сердито).

В моей старой цмс не то что работает, а очень шустро работает за счет Lazy initilizating

-~{}~ 18.02.10 17:03:

Да никак я не предлагаю опыта у меня может с год

У тебя светлая и конструктивная голова. А опыт - знаешь, я люблю часто говорить на собеседованиях кандидатам которые дубы, но начинают мне доказывать что у них опыт в 2 раза больше чем у меня: " У тебя опыт - 1 год, повторенный 10 раз"

AmdY · 18 Фев 2010

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

fixxxer · 18 Фев 2010

Я писал выше:

Итого у меня есть такое понятие как Engine - например http, json, xml, socks.
И я передаю в объект $Render->render( $View, $Engine )
Который уже передает на отображение в нужном мне формате - если http - то подключит шаблоны и отобразит, если в json - то в формате json( для аякс запросов, например), надо XML - получите, надо куда то по сокетам отправить ответ - получите и т.д.

Так же рендер отвечает за кеш и т.д.

Хе-хе. У меня практически то же самое, только названия другие =)

HraKK · 18 Фев 2010

AmdY

когда повесил в шапку контроллер для логина, который по идее и должен обрабатывать данные и делать редирект?

Если пост - то отправляю на контроллер, тот обрабатывает и вызывает метод redirect(); Ну аякс - вернет ответ в формате json и отредиректит если надо.

или контрол вывода новости, который распологается ниже хлебных крошек и не имеет возможности сообщить им в какой категории ты находишься?

Контент( страницы, новости если мы сейчас в них находимся и т.д.) не вызывается из шаблона, это есть в первоначальном шаблоне - главном View. По этим же данным и строятся крошки. Шаблон подгружает только периферию.

я не понял про экранирование

Она у меня и стоит
Core_View_Abstract

PHP:

protected $escape = true;

Экранирует все что не указано не экранировать.

fixxxer

Хе-хе. У меня практически то же самое, только названия другие =)

Умные решения выливаются в паттерны)

AmdY · 18 Фев 2010

HraKK вот и у меня примерно так, лишний редирект, вместо страницы уже для авторизованного пользователя. а данные передать можно только вниз по лестнице вызовов, хотя ситуации редкие, но приходится использовать костыли.

HraKK
по данному сабжу, насколько я понял, ты отказался от подхода только потому, что решил использовать другие методы(грабли)?

HraKK · 19 Фев 2010

AmdY

вместо страницы уже для авторизованного пользователя

Не понял? А как по другому? Ты имеешь ввиду сразу отдать страницу? Так, так нельзя делать потому что останется _POST запрос, и человек нажав Ф5 - увидит сообщение, а если надо передать контроль то делается элементарно - например 404 контроллер:

PHP:

try 
			{
				$this->getRouter()->addPattern( $pattern )->get( 'controller' );
			}
			catch( Core_Router_Exception $e )
			{
				$Controller = new Modules_Page_Controller_404( $this->getView() );
				return $Controller->dispatch();
			}

Если надо какую-то определенную странницу а не контроллер:
то

PHP:

try{
$Auth // no Exception

return new Core_Respounse( $this->getApplication()->getRequest()->setRequest( 'user/authorize' ) );
}

по данному сабжу

Да, метод этот хороший, я не спорю, НО, новые грабли, работают лучше. Правда, пока только в голове

Реальный проект только делаем на этом фреймворке( пишу его 3 недели, завтра должен закончить до состояния когда его можно начинать имплементировать)

AmdY · 19 Фев 2010

угу, редирект только хотелось бы делать до обсчёта страницы и начала вывода, здесь уже аспектами попахивает.

а твои новые грабли тоже не учитывают работу с блочными функциями, очень хочется от левых шаблонизаторов избавиться.

HraKK · 19 Фев 2010

угу, редирект только хотелось бы делать до обсчёта страницы и начала вывода, здесь уже аспектами попахивает.

я выше описал - обсчитывается ДО обработки или вывода страниц.

тоже не учитывают работу с блочными функциями

пример?

Ирокез · 19 Фев 2010

Как я в начале и говорил, все плавно перешло к обсуждению архитектуры

HraKK, собственно у меня поддерживается только три (в твоей формулировке) Engine, http, ajax, soap, (cron я не считаю), но с ними прекрасно справляется контроллер. хз что архитектурно лучше.

Но есть у меня серьезные опасения что подход к шаблонизации очень сильно связан с реализуемым проектом,

к примеру если ERP или какой-либо сервис связанный с изменяемым количеством данных(блоков), то подход описанный в топике выгодно будет отличаться.

Если сайты визитки, информационные сайты, магазины, т.е. там где состав информации и блоков не очень сильно колеблется, то вполне достаточно и native php

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

или я не прав?

AmdY · 19 Фев 2010

пример был в самом начале

Код:

<widget:table> 
    <table:column title="URL" align="left" width="240px"/> 
    <table:group title="Group1" /> 
    <table:column title="Column1"/> 
    <table:column title="Column2"/> 
    ... 
    <table:rows rows=$Top10 /> 
</widget:table>

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

Fortop · 19 Фев 2010

изменение вёрстки таблицы вызовет необходимость менять чёрт знает сколько шаблонов

почему?

Тюнниг php как шаблонизатора.

К.О.

Двинутый новичок

Новичок

Мудак

Новичок

Пью пиво

бессмертный пони

Мудак

Новичок

Мудак

Пью пиво

К.О.

Мудак

Пью пиво

Мудак

Пью пиво

Мудак

бессмертный пони

Пью пиво

Новичок