Использование Шаблонов технологии, принцип и все ЗА и ПРОТИВ

[dacuan]

Sheryld
Было бы интересно увидеть результаты эксперимента

[Sych]

результат на лицо http://sybe.dotgeek.org/ время генерации говорит за себя :-)

[dacuan]

Sych
Время генерации, минимум 0.014, максимум 0.9
Не лучшие показатели :\ На каком сервере стоит система?....

[Sych]

Сейчас все работает на забугорном халявном хостинге так что как говорится системка показывает себя в боевых условиях тк на этом же сервере хостится еще около 5000 проектов.

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

На локальной машине время генерации 1 мега XML + XSLT преобразование не превышает 0.1-0.3 се,обычные странички генерятся за 0.01-0.05 сек.

Хотя я сомневаюсь что в реальных условиях будут файлы такого размера.

Система пока сырая - но дает представление о своей работе и потенциале.

Кому интересно могут написать в приват - Я дам потестить, для работы надо php5.

[Hubbitus]

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

Плюс неоспоримым преимуществом является конечно то что я могу реализовать впринципе любую необходимую конструкцию в нем, а не только тем пользоваться что мне предлагают. Предвосхищая крик многих типа "а в подходе ХХХ уже все это есть и предусмотрено" хочу спросить сколькими вообще возможностями из имеющихся там Вы пользуетесь обычно, и сколько процентов из общего числа Вы использовали хоть раз?! А время-то на обработку и условия тратится...

Да и потом как же быть с тем так и не закрытым вопросом должен ли Дизайнер (верстальщик) учить новый язык, например XML? Какая разница, почему бы ему в таком случае не выучить 20 конструкций PHP?

Вобщем мне в любом случае оказалось приятнее своя реализация. Как говорится "своя рубашка ближе к телу". Это конечно не аргумент, но это крайне важно, когда нужно решить нестандартные задачи....

[Sheryld]

KTemplate. использую на 100%.

хотя есть и свои наработки.

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

проект где-то до 50 страниц (например сайт знакомств или форум): можно использовать подход header-body-booter. тобишь общие части просто загнать в отдельный файл и вставлять его на каждой странице.
Коенчно, в этих двух случаях вы не увидете никакого разделения дизайна и кода, и это перекроет возможность кодеру прикрутить дизайн к программе самостоятельно, но даже если программист сам это сделает, выигрышь времени будет на лицо.
Использовать шаблоны я бы рекомендовал только в больших проектах (более 50 страниц). Еще один огромный плюс шаблонов: при условии удачного соглашении об именовании переменных, методов и классов и использовании ООП вместе с шаблонами, проект выполненный с использованием шаблонов дает преимущество в поддержке.

[Hubbitus]

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

Ну вот тут не совсем согласен. Грамотно написанный класс шаблонов (на любой технологии, главное удобный в использовании) только экономит время разработки сайтов с его использованием.

[RaZEr]

проект страниц на 10 не больше (есть и такие, например порно сайт)

Порно сайт в 10 страниц ... 5 превью и 5 - биллинг

[Ruferut]

Я использую php_templates и chtemplate.
Оба движка работают как extension к php, поэтому скорость работы по сравнению с самим пхп (<?=$content?>) практически минимальна (т.е. почти нет вообще). По сравнению с аналогами (smarty, fasttemplate, xtemplate даже при использовании ими кэширования) генерация с помощью этих движком происходит в разы быстрее. В php-templates правда тоже встроен механизм кеширования в вирт. памяти.
За то плюсы на лицо: быстрая генерация страницы, полное разделение дизайна от кода.
Минусы: то что используется как библиотека, поэтому надо просить хостера чтоб установил.

[Hubbitus]

Ruferut:
поэтому скорость работы по сравнению с самим пхп (<?=$content?>) практически минимальна (т.е. почти нет вообще).

Это круто сказано, конечно можно догадаться что имелось ввиду, но написано что "скорость работы минимальна, тоесть вообще не работает"

Ну со скоростью вроде понятно, есть более быстрые и более медленные решения. Я вообще не люблю стороннних продуктов, поэтому написал вобщем-то свой класс шаблонов, открытым остается самый главный и принципиальный вопрос - разделение и наглядность!

Итак, мне все-таки пришломь разбираться со Smarty в одном из проектов (многим известный X-Cart Gold), приведу пример шаблона на смарти:

{section name=cat_num loop=$categories}
    {capture name=block}
        {section name=cat_n loop=$categories[cat_num].sub}
            • <a class="leftLinks" href="home.php?cat={ $categories[cat_num].sub[cat_n].categoryid }"> { categories[cat_num].sub[cat_n].category|escape }</a><br>
        {/section}
    {/capture}
    {include file="block.tpl" title="<a class=insideTitle3 href=home.php?cat=`$categories[cat_num].categoryid`>`$categories[cat_num].category`</a>" content=$smarty.capture.block extra="class=bgInside5"}
{/section}

Это простенький (!), полностью реальный, работающий шаблон с сайта, для формироания списка категорий в магазине, включающийся в остальные страницы.
Итак главный вопрос: Это наглядно для дизайнера, не разбирающегося в программировании вовсе???? Это реализует концепцию разделения кода и содержания?
Только не нужно говорить, типа "и не нужно использовать Смарти, вон в ХХХ все наглядно и просто", когда шаблонизатор обрастает возможностями и функциональностью, его синтаксис неизменно усложняется, с этим, надеюсь, никто спорить не будет. Тоесть, при том что я сам написал шаблонизатор для собственного использования, и мне с ним удобнее теперь работать, я никак не могу нормально разобраться во всем этом принципе: как же это все должно быть в идеале....

[Sheryld]

у каждого свой идеал. вместо "навороченных" шаблонов нужно использовать xslt. там это все уже есть и даже больше.

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

мне нравиться делать следующим образом:

есть шаблон. вся его обработка идет в коде. пример:

<!-- BEGIN list -->
<table>
   <!-- BEGIN list_item -->
     <tr>
       <td>
         {item_title}
       </td>
     </tr>
   <!-- END list_item -->
</table>
<!-- END list -->

Вся обработка идет в php.

1. разделение кода.
2. простота.

p.s. мне идеально подошел KTemplate.

[RaZEr]

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

Не согласен. Дизайнер задумывал дизайн и соответственно он сверстает лучше кого бы то нибыло. А как внедрить это вопрос к разработчикам тех. части (хотя часто всё обходится header-footer заменой).

[Sheryld]

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

у тебя есть картинка, макет, описание и т.д.
твоя задача выдать тоже самое, но в html.

[Hubbitus]

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

Sheryld:
у него должна быть некоторая подготовка.

???
Вы считаете что он должен в любой момент кидаться изучать как программисту в очередной раз

Sheryld:
нравиться делать следующим образом

, в очередном проекте, и не важно совсем что это будет: Smarty, xslt, KTemplate или многие, многие другие?

И вот теперь, тут, мы возвращаемся к самому моему первому и принципиальному вопросу, заданному в самом начале этой темы, и как-то оставленном посути в стороне, отвлекаясь на всякие частности, на альтернативы и т.д.: А не проще ли Дизайнеру (пусть верстальщику) выучить десяток-два конструкций на PHP, тех что ему необходимы для верстки??? Это не универсальнее вообще? Тоесть разделение возможно и нужно, но нужно ли его делать "полным" и для этого изобретать велосипеды и новые технологии, кому какие вздумается?

[Sheryld]

еще раз и все по-порядку.

1. я уже давно не делаю вставок php кода в html. просто считаю это не правильным подходом. отсюда и идут шаблоны(при всех остальных плюсах). более того, там где это возможно(по срокам) стараюсь всегда делать четкое разделение приложения на уровни(data layer, biz, logic, output, etc).

обычно у меня так:

1.база данных.
2.класс, инкапсулирующий всю логику.
3.сборка страницы.
4.шаблон.

уровни могут "общаться" только с соседними.

если нету времени, 2-ой уровень убирается.

2. xslt это язык программирования. дизайнер его знать не обязан, а хорошему верстальщику - самое оно.

3. ответ на твой вопрос для меня очевиден: не проще и не правильно.

[Hubbitus]

Sheryld:
1. я уже давно не делаю вставок php кода в html. просто считаю это не правильным подходом.

"просто неправильный подход" давай остаим в детском саду ответ, ок?

Sheryld:
если нету времени, 2-ой уровень убирается.

Гы, самое главное, логика приложения убирается??? Оригинальный подход. И потом разве БД не входит в 2, ведь для обеспечения логики работы с данными она какраз и используется...

Sheryld:
2. xslt это язык программирования. дизайнер его знать не обязан, а хорошему верстальщику - самое оно.

Тоесть ты настаиваешь, что если верстальщику (ну пусть, раз именно тебе так хочется, верстальщику, хотя я согласен с RaZErом и никак не могу понять почему принципиально дизайнер не может сверстать), чтобы нормально работать с тобой нужно знать XSLT? А потом он со мной будет работать, я а скажем (пример), Смарти люблю, то и его ему узнать "самое оно"? А с Петей программистом, которому, скажем, KTemplate нравится, тут уже он "самое оно"??? Тоесть получатся программистам в простейшем случае (не нужно утрировать и придираться, я вобщем говорю) нужно знать только PHP, а бедному верстальщику изучать каждый раз то что программисту придет в голову???

Sheryld:
3. ответ на твой вопрос для меня очевиден: не проще и не правильно.

Смотри самое начало этого поста.

[Sheryld]

2Hub

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

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

class Item extends AbstractItem //base item
{
  var $itemInfo = array(
 	'id'=>0,
 	'catid'=>0,
 	'title'=>''
 	);
 	
  var $itemCollection = array();
  .
  .
  .
function GetItemById($itemID)
 	{
		$db = new MySql(null,null,null,null);
 		$db->MySql_Connect();
 		$db->MySql_SelectDb();

 		$selectQuery = "select itm_ID, cat_ID, itm_TITLE from cat_item where itm_ID = " . $itemID . " limit 1";

 		$db->MySql_QueryDb($selectQuery);

 		if ($db->dbResult != null)
 		{
 			while($row = mysql_fetch_assoc($db->dbResult))
 			{
 				$this->itemInfo['id'] = $row['itm_ID'];
 				$this->itemInfo['catid'] = $row['cat_ID'];
 				$this->itemInfo['title'] = $row['itm_TITLE'];
 			}
 			return 0;
 		}
 		
 		return -1;
	
 	}

   .
   .
   .
}

страница "x" будет в таком случае следующей:

$item = new Item(); //default constructor
if ($item->GetItemById(1) == 0)
{
  print_r($item->itemInfo); 
}

в чем суть?

в том, что страница "x" ничего не знает ни о бд, ни о запросах, вообще ни о чем, вся ее задача это вывести данные на экран.

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

если же нету времени, то я переношу логику на 3-ий этап.

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

про дизайнера - я все написал. добавить мне нечего.

p.s. в данном случа программист должен будет распарсить шаблон, а верстальщик собвственно их сделать.

пример опять же:

дизайнер сделал макет, эских или предвариетльную верстку:

элемент "список"

верстальщик сделал:

<!-- BEGIN list -->
<table>
   <!-- BEGIN list_item -->
     <tr>
       <td>
         {item_title}
       </td>
     </tr>
   <!-- END list_item -->
</table>
<!-- END list -->

программист(псевдо шаблонизатор):

$listTpl = $tpl->fetchblock("list");
 
foreach($item->itemCollection as $itemObject)
{
  $listItemTpl = $listTpl->fetchBlock(list_item);
  $listItemTpl->assign("item_title",$itemObject["title"]);
  $listTpl->assign("list_item",$listItemTpl );
  $listItemTpl->reset();
   
}

$tpl->assign("list",$listTpl);

[Hubbitus]

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

Sheryld:
я совершенно не настаиваю на своем подходе.

Я и не убеждаю никого что твой подход плох или хорош, у всех свои подходы к написанию приложений, в чем-то я согласен с твоим подходом (во многом), в чем-то нет, но не в этом же дело!!! Здесь я спрашивал всех именно насчет той части "верстальщик сделал:..." и принципиально кто и как это должен обрабатывать, на каком принципе (меня мало интересна реализация именно тобой бизнес-логики и общения с БД...).

Итак, приведенный тобой код того что "верстальщик сделал" так красив просто и понятен только пока .... он так прост! Я же привел пример к чему приводит наращивание возможностей, на примере Смарти. А подобного не избежать никак помоему - полюбому и верстальщику нужно будет все больше возможностей и универсальности... Дак вот где здесь компромисс??

[Aeon]

Здесь есть ещё неплохая статья на эту тему (но на английском).
http://www.massassi.com/php/articles/template_engines/