Концепции работы шаблонизатора

[Crys]

к чем ты это написал?

К твоему посту на предыдущей странице. На мой взгляд, на фразу "..... + незнакомый и сложный и НАВЕРНЕКА не гибкий синтаксис" опонент спокойно ложил, т.к. нет показа альтернативы, которая как бы "лучше".

Вот я конкретно и написал, что:

{html_select_date prefix="date" time=$article.dt start_year="-5" end_year="+1" field_order="DMY" month_format="%m"}

на PHP выглядет не менее понятно:

<?php echo html_select_date('date',$article['dt'], '-5', '+1', 'DMY', '%m')?>
или так:
<?php echo html_select_date(array('prefix'=>'date', 'time'=>$article['dt'], 'start_year'=>'-5', 'end_year'=>'+1','field_order'=>'DMY','month_format'=>'%m'))?>

 

[c0r0ner]

Выскажу свое ИМХО. Неважно есть шаблонизатор или нет и какой он. Главное что все было сдлано с умом. Но также не стоит забывать о людях, которые могут работать над проектом после вас.


Написать код, понятный компьютеру, может каждый, но только хорошие программисты пишут код, понятный людям
(с) Мартин Фаулер

 

[Dagdamor]

Имхо, удобный шаблонизатор должен позволять вытворять что-нибудь наподобие:

<insert:menu>
<insert:menuItem page="index" title="На главную" />
<insert:menuItem page="catalog" title="Каталог товаров" />
<insert:menuItem page="contacts" title="Контакты" />
</insert:menu>

т.е. вставлять одни шаблоны в другие, попутно передавая им параметры, которые затем в этих вспомогательных шаблонах используются. Это позволяет, с одной стороны, собирать дизайн как из деталей конструктора, вынося сложные/повторяющиеся блоки в отдельные шаблоны, и с другой, отделять оформление от содержания, как здесь. Весь дизайн меню находится в шаблонах menu и menuItem, и если меняется оформление меню - достаточно изменить эти шаблоны, а если добавляются новые пункты - достаточно изменить фрагмент, который их вызывает.

Также удобный в моем понимании шаблонизатор должен позволять использовать шаблоны-"обертки":

<insert:design> // общее для всех страниц оформление
...данные текущей страницы
</insert:design>

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

 

[Develar]

Dagdamor
Не уходи в сторону от темы. Про макетирование я уже говорил - и оно тут оффтопик - тема про шаблоны без управляющих структур.

 

[Dagdamor]

Хм, ладно... хотя тема вообще-то называется "Концепции работы шаблонизатора", и начали ее не вы

А что такое в вашем понимании "управляющая структура"? Если только условия и циклы, тогда читайте выше. Если все, что сложнее plain html... тогда и вывод обычной переменной - тоже управляющая структура и в вашем шаблонизаторе такого не должно быть.

С шаблонами, которые не позволяют организовывать условия/циклы, я имел дело... например, в vBulletin 2 версии. Там тоже все разбито на "кирпичики", и PHP код собирает страницу в единое целое. Крайне неудобно - особенно когда на странице отображается много динамических данных. Для статических сайтов такая система годится, но как только появляется что-нибудь посложнее - начинается симбиоз верстальщика и программиста.

 

[__Lex]

c0r0ner

> Написать код, понятный компьютеру, может каждый, но только хорошие программисты пишут код, понятный людям
(с) Мартин Фаулер

*жму руку*
Писать для себя - удел новичков (вернитесь к проекту через год, поймёте меня)

 

[Rammstein]

Вобщем, юзайте смарти. Как бы его тут не угнитали, а дизайнеру проще со смарти поладить. А если уж вместо { и } использовать, например, <cms: и >, то десингеру проще раза в два будет - видит те же теги.
В то же время, за счёт компиляции увеличивается скорость, причём значительно.

 

[Crys]

не менее понятно?? это называется понятно? имхо вот понятно.

плюсы - список не привязан ни к какому блоку. зачем попросту выносить список из шаблона? смысл?

Умница... Молодец. Можешь взять с полки пирожок.
На смарти вывод списков для даты делается в одну строчку. На php можно сделать также. Именно это я показал. Твой код - совсем из другой области.

 

[__Lex]

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

 

[confguru]

Вобщем, юзайте смарти

После оптимизации одного крупного проекта - остался
1 тормоз - С М А Р Т И
Короче смарти не рекомендуется если посещаемость будет выше 2000-5000 хостов.

 

[Dmitriy]

admin

Короче смарти не рекомендуется если посещаемость будет выше 2000-5000 хостов.

Выдерживает и 30 000 - 50 000, всё в ваших руках

 

[Фанат]

перестаньте говорить о смарти, как о шаблонизаторе.
когда начинаешь спрашивать у поклонников этой избушки на курьих ножках о её достоинствах, не услышишь НИ ОДНОГО СЛОВА про шаблоны.
система кэширования
view представление
структура сайта
что угодно - то только не шаблон.
а уж как шаблон - это, конечно, через зад автогеном. на пхп написан язык, который транслируется обратно в пхп.

 

[alexhemp]

Это вопрос терминологии.

Смарти в том числе предоставляет и язык разметки шаблонов.

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

Самописные "шаблонизаторы" как правило медленнее смарти, и совершенно не расширяемы.

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

Я считаю - специалист сам знает - а чайнику - смарти.
С eAccelerator смарти работает очень даже быстро, и десятки тысяч хостов и сотни тысяч хитов в сутки - нормально работает, загрузка слабенького P3-1000 в районе 2-3% при этом там еще поисковый демон крутиться.

 

[__Lex]

Автор оригинала: DonGan
это упрёк в чью сторону?

Акстись, тут нет упрёков.

 

[Toxic_Cat]

Отдам свой голос в поддержку вот такого метода

Красивый PHP код. Зачем использовать PHP код для создания шаблонизатора, который делает на выходе тот-же PHP код?

Когда был новичком (ну и сейчас им являюсь), работал с первой в своей жизни компании.
Так вот, у них и был такой "движок", что {CONTENT} заменялся на подобную ему переменную.

Честно сказать? После месяца работы мне показалось это полной чушью! Возможно я приведу какие-то невязкие аргументы, но:
- Клиент НИ РАЗУ не лазил по шаблонам и что-либо исправлял (почему я тогда не могу вставить PHP код?)
- Я постоянно терял "убогие" надписи {MENU}, {CONTENT} возможно это конечно моя вина.

В общем я считаю это ненужным делом. В 99% случаев спокойно обходится без так называемых "шаблонизаторов".

 

[alexhemp]

У меня все наоборот.

Жизненный цикл проекта такой

1. Разработка программистом сайта
2. Создание дизайнером макета в PSD
3. Верстка - создание шаблонов, верстальщик создает HTML код, программист на этой базе создает "главные" шаблоны (описывающие всю страницу). Далее верстальщик создает HTML для "внутренних" блоков - содержание отдельных разделов, возможно видоизмененные меню. По этому поводу они с программистом договариваются заранее.
4. Проект сдается заказчику, и далее его ведет сопровождение, мелкие изменения делают в шаблонах, прямо через Web-интерфейс. Крупные доработки - безусловно обращаются к программисту и верстальщику и иногда к дизайнеру.

Сайты в основном небольшие (это не значит что посещаемость их мала - бывают 50 страниц в итоге, а посещаемость 5 тыщ хостов в сутки.)

Концепция шаблонизатора - должна основываться на типовых процессах и универсального рецепта наверное нет.

 

[Фанат]

Toxic_Cat
в приведённом по ссылке примере очень много лишнего пхп кода.
впрочем, та же беда касается и смарти-шаблонов.

 

[Toxic_Cat]

Автор оригинала: Фанат
Toxic_Cat
в приведённом по ссылке примере очень много лишнего пхп кода.
впрочем, та же беда касается и смарти-шаблонов.

Согласен, но лучше я буду читать PHP код, чем никому не нужный SMART'y псевдокод


OFFTOP: Если у кого будет время, пожалуйста, напишите свои варианты представления данного кода.
Интересен вопрос "Кто и как совмещает PHP и HTML"
Сам код

 

[Rynor]

Знание хытымыл в вебе это все ж таки азы. Поэтому.
Дизайнер делает графические макеты и режет в html рыбу + css.
Программист работает с html макетами (его дело - как, шаблон или инклуды и т.д.) и javascript.
Непонятки обсуждаются. Не думаю, что это экономия на спичках, верстальщик в небольших проектах (их в сети - большинство) просто не нужен.

Я как программист предпочитаю вынесение динамичных HTML блоков в php фунции. Мне так больше нравится, чем куча php тегов в HTML, как в примерах выше

<html>.....(здесь идет блок новостей, например, таблицей или чем угодно)<?=www->newsList(10)?>

в методе newsList() идет генерация html через echo или return.

 

[Crys]

<html>.....(здесь идет блок новостей, например, таблицей или чем угодно)<?=www->newsList(10)?>

в методе newsList() идет генерация html через echo или return.

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