Очередное столкновение логики представления с логикой приложения.

[Alexandre]

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

Raziel[SD] и я о том же.... с переносом логики отображения в шаблоны, их сложность растет, правильно ли это - вот в чем вопрос?
и еще раз подчеркиваю, что нет разницы, написано это в xml или на смарти... Этот же шаблон можно переписать и на смарти, сложность от этого не измениться

 

[Дмитрий Попов]

Я против того, чтобы шаблонизатор превращался в CMF (как у ДК), но +1 за активные шаблоны.

А Вам не кажется, что это предложение "несогласованно"?

 

[texrdcom]

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

 

[Фанат]

О каких заданиях речь? что за задния?

При чём здесь смарти заставляет? Вопрос не в том, кто заставляет, а в том - нужно ли это или нет?

 

[Нечто]

Дмитрий Попов

А Вам не кажется, что это предложение "несогласованно"?

Почему же? На мой взгляд Templier берет на себя слишком много для движка шаблонов, но так ДК понимает "шаблонизатор"..
В моем случае активные шаблоны только предоставляют упрощенный интерфейс для работы с dao по тому же принципу, что и "компоненты" у ДК: верстальщик задает параметры вывода, контекст данных ограничен открывающим/закрывающим тегом компонента. Это можно назвать фреймворком вывода (представления), но никак не комплексным веб-приложением, коим является CMF.

 

[Domovoj]

Автор оригинала: Alexandre
и все-таки не понятно, где должен задаваться цвет, на уровне
шаблона или уровне Приложения??

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

Как быть в этом случае - лезть в логику приложения или все решать на уровне корректировки шаблона??

Хочу отметить, что интерфейс данных ( буть то массивы для smarty или данные xml для XSLT) НЕ изменился

Меняем только внешнее представление

А что мешает положить цвет в CSS. А в коде просто определять имя CSS класса, ответственного за группу конкретного пользователя?

 

[2NetFly]

Автор оригинала: Domovoj
А что мешает положить цвет в CSS. А в коде просто определять имя CSS класса, ответственного за группу конкретного пользователя?

Написано же "Через день - два мы цвет строки решили оставить белый, а статус пользователя отображать иконкой". CSS - это решение конкретной проблемы. На самом деле не все так просто.

 

[Domovoj]

А вообще кто-нибудь пробовал делить приложение на 3 уровня, а не на 2?

1. Бизнес-логига (выборка данных, выполнение операций с данными, вычичсления, и т.д.)
2. Логика отображения (подготовка имён CSS классов, создание массивов на основе настроек магазина (это про кол-во столбцов), и т.д.)
3. Файлы-шаблоны, просто отображающие (с минимальным кол-вом IF и FOREACH) данные, подготовленные в 2.

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

 

[Screjet]

Domovoj
Стандартная практика. п.1 = это модель. Она то и управляет тем, что будет отображаться на командном уровне (Процесс "как будет отображаться" = автоматический, управляемый логикой шаблона/шаблонизатора).

 

[2NetFly]

Автор оригинала: Screjet
1. Бизнес-логига (выборка данных, выполнение операций с данными, вычичсления, и т.д.)

Стандартная практика. п.1 = это модель.

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

БД <= DAO <= Helper <= View

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

Представьте, что необходимо сделать выборку из 5 таблиц, каждая из которых представлена в домене отдельным классом. Реализуем либо в DAO либо в хелпере метод, выполняющий нужный запрос, и возвращающий в общем случае Record Set или проще говоря массив строк таблицы, которые готовы для использования в шаблоне. И никаких манипуляций с объектами, никаких объектов модели в шаблонах. Все просто и красиво.

-~{}~ 17.05.05 19:35:

Автор оригинала: Domovoj

2. Логика отображения (подготовка имён CSS классов, создание массивов на основе настроек магазина (это про кол-во столбцов), и т.д.)
3. Файлы-шаблоны, просто отображающие (с минимальным кол-вом IF и FOREACH) данные, подготовленные в 2.

В принципе это и есть описываемая схема с хелпер объектами. В случае с активным шаблоном, шаблон запрашивает у хелпера нужные данные, например "дай мне список пользователей, с автаром, количеством постов, и количеством штрафных очков", а хелпер возвращает ему данные в обычной структуре. И шаблону (представлению) не нужно знать, что на самом деле выборка была произведена из 4 таблиц, он лишь знает, какие поля может использовать при отображении.

 

[Фанат]

Ребят, а как в ваших крутых шаблонах реализуется такая вещь, как выбор в форме даты с помощью трёх селектов.
и отметка выбранной из базы/текущей.

соответственно, контрольное задание - поменять шаблон вывода с "в линию" на "в столбик" и порядок следования инпутов с "d m y" на "y m d"

 

[2NetFly]

А чем плохи отдельные теги / функции для дня / месяца / года?

 

[Фанат]

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

тем плохи, что они не имеют никакого отношения к ШАБЛОНАМ HTML.

Шаблон мы придумали для того, чтобы можно было вносить изменения во внешний вид приложения.
И единственный вопрос, который инетерсует лично меня - именно использование шаблонов.
А не игра в конструктор "Лего", которая к шаблонам не имеет ни малейшего отношения и здесь - оффтопик.

 

[WeirD]

В Smarty

Исходно ("d m y" в линию)
{html_select_date time="$time" field_separator=" " field_order="DMY"}

С изменениями("y m d" в столбик, с яваскриптом у каждого селекта)
{html_select_date time="$birthday" field_order="YMD" field_separator="<br>" all_extra="onclick='alert(\"test\")'"}

 

[Фанат]

ахеренть можно.
я предполагал, что кто-то напишет специальный КОНСТРУКТОР для ВВОДА ДАТЫ ТРЕМЯ СЕЛЕКТАМИ.
но чтобы это уже было готово...

Как я понимаю, про персональные экстры можно даже и не спрашивать... мда, ничего не скажешь. ХТМЛом тут и не пахнет, но все дырки закрыты. То есть, получается, что существует специальная профессия - смарти-верстальщик.
И он - единственный, кто сможет внести эти изменения.

Нет, ребята, если меня теперь спросят, имеет ли смысл пользоваться смартей, то я отвечу - бегите от неё, как от чумы, прямиком в объятия XSLT.
потому, что читать её мануал вы окончите аккурат к пенсии.

Я всё больше начинаю любить XTPL и даже XSLT, поскольку они обе хотя бы отвечают стандартам. Первая - HTML, вторая - своему собственному, но, хотябы,. международно признанному.

 

[Нечто]

В моем случае таким будет выбор:

<tpl:dateform year="yearfield" month="mymonth" date="date" var="somedate">
<!-- дизайндизайндизайндизайн -->
<!-- яваскриптяваскриптяваскрипт -->
... <select name="yearfield"><option>...</option>...</select>...
... <select name="mymonth"><option>...</option>...</select>...
... <select name="date"><option>...</option>...</select>...
<!-- дизайндизайндизайндизайн -->
</tpl:dateform>

То есть спец-тег заменит тег <form ... >
А таким вывод:

Вы выбрали: <tpl:date format="Y.m.d" var="somedate" />

 

[2NetFly]

После ознакомления с документацией по Xtemplate у меня сложилось впечатление, что он не предназначен для использования с активными шаблонами и реализации паттерна "представление диспетчера". Если это так, имеет смысл сравнивать не конкретные шаблонизаторы, а подходы к реализации представления, которые были описаны выше, ибо шаблонизаторы пишутся "под диктовку" этих подходов.

 

[Demiurg]

Фанат
Точно так же на вопрос стоит ли использовать PHP можно ответить, что не надо, бегите к перлу. Смарти пошел по тому же пути, что и php завоевать популярность подобными тегами и возможностями грязными хаками с непосредственным использованием php. Стандарт - это хорошо, но иногда он слишком дорого стоит.

 

[Дмитрий Попов]

Фанат

Ребят, а как в ваших крутых шаблонах реализуется такая вещь, как выбор в форме даты с помощью трёх селектов.
и отметка выбранной из базы/текущей.

Я чего-то не понял вопроса совсем, да...
А в чем проблема?

 

[Фанат]

В том, что мы видим здесь отрыв от реальности.
программисты витают в своих программистских облаках - контроллерах, вьюерах, мотороллерах...
а про верстальщиков все забыли.
про возможность поменять HTML. Про то, ради чего всё затевалось.