Smarty VS <? print ?>

[The employer]

Автор оригинала: *****
Ахахахахаха! Насмешил.
Попал, как говорится, пальцем в небо.

Насмешил? Ну-ну.

Внимание

Статус проекта — полуэкспериментальный, но я считаю текущую версию вполне работоспособной. В силу параноидального отношения к качеству проекта, 100%-я стабильность и обратная совместимость до версии 1.0 не гарантируется.

так.
хслт, смарти пхп - ваш выбор в этом случае.

Ясно, спасибо.

-~{}~ 02.08.09 19:33:

Автор оригинала: fixxxer
Проблемы со смарти скорее идеологические, чем технологические.

Идеологические?

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

Как всю жизнь показывает практика, PHP (вместе со своими шаблонами и прочим) никогда не является узким местом. Всегда проблемы начинаются с базы.

Оно, в принципе, и понятно - веб-приложение отлично параллелится, потому что у каждого экземпляра нет ничего общего, все общие данные лежат в memcached (что тормозит редко) и в базе (а вот тут ужее все хуже). Так что при возникновении проблем именно с PHP (а не с чем-нибудь еще) просто добавляется еще один сервер, и все. Лишь бы архитектура приложения не препятствовала, но это уже руки.sys.

С другой стороны, если ограничиваться небольшим набором конструкций - if, foreach - то не вижу никаких проблем в использовании и plain php-шаблонов. Примерно то же самое и получается.

Если подходить к вопросу серьезно, то дело не в наборе конструкций. Дело в возможности расширения языка шаблонов, во включении в этот язык операторов, специфичных для данного приложения или данной предметной области. В ruby on rails, к примеру, нечто подобное называют хелперами.

Например, есть задача написать приложение, где часто нужно иметь дело с иерархическими выпадающими списками. В smarty можно сделать plugin, инкапсулирующий в себе всю логику поведения и отображения этих списков.

А вообще, для начала надо определиться с требованиями к template engine - при наличии точного списка требований (а это зависит от ситуации) выбор обычно становится очевиден.

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

Первая часть должна решать вопросы проверки входных параметров запроса, проверку прав доступа, извлечение объекта из хранилища, etc.

Вторая часть должна быть полностью посвящена вопросам отображения объекта в принятом языке - будь то common xml, xhtml, json или вообще некий специфичный протокол типа IFX.

Этот подход можно реализовать с использованием чистого PHP, можно с использованием blitz. Но smarty заточен на это прямо "из коробки".

 

[Groove]

Автор оригинала: The employer
Интересная штука, но сыроват пока.

отвечу ссылкой: http://habrahabr.ru/blogs/webdev/18695/#comment_385969
для хабра и автокадабры он оказался не "сырым"

 

[The employer]

Автор оригинала: Groove
отвечу ссылкой: http://habrahabr.ru/blogs/webdev/18695/#comment_385969
для хабра и автокадабры он оказался не "сырым"

Интересно, спасибо.

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

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

 

[fixxxer]

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

В Blitz-е, кстати, хелперы реализуются элементарно через __call. Другое дело, что если шаблон нашпигован хелперами, то постоянные переключения blitz<->php и парсинг в __call бьют по производительности.

 

[grigori]

Смарти ускоряет скорость разработки.
Выбор даты одним оператором, генерация списка <option> из массива, кеширование, многоязычность и т.п. довольно приятны.

На последнем проекте я убедился, что jQuery с плагинами ускоряет ее еще больше (без учета research-а, впрочем).
Кроме того, AJAX "поглощает" все эти прелести смарти.
Визуальные элементы генерятся JS намного лучше.

Если в проекте можно пренебречь пользователями без JS ради классного интерфейса - смарти не нужен.

 

[The employer]

Автор оригинала: fixxxer
У меня есть практика, как подтверждающая один тезис, как и другой. Нет серебряной пули, ага?

Это точно. Но мы все судим субъективно, такова человеческая природа. Давай я расскажу тебе почему считаю свой тезис более верным, а ты мне приведешь свои контрпримеры.

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

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

Однако есть вещь, которая еще хуже чем излишняя гибкость инструмента. Называется она "недостаточное разделение уровней абстракции".

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

При продвижении вниз по уровням абстракции очень важно не забегать далеко вперед и не слишком оглядываться назад. Основное количество ошибок проектирования - это попытки думать на нескольких уровнях абстракции одновременно. Такова, например, природа "преждевременной оптимизации" - попытка "думать вниз" (конкретизировать способ исполнения) раньше времени. А принцип KISS (как и YAGNI) призывает не "думать вверх", не обобщать задачу сверх необходимого.

Так вот, жесткое (на уровне засеттил данные и вызвал display) отделение кода контроллера от кода представления - способствует изоляции уровней абстракции. В этом смысле классическая практика использования smarty делает правильное дело.

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

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

В Blitz-е, кстати, хелперы реализуются элементарно через __call. Другое дело, что если шаблон нашпигован хелперами, то постоянные переключения blitz<->php и парсинг в __call бьют по производительности.

Вот уж что-что, а проблемы производительности PHP и связанных с ним инструментов меня совсем не волнуют. Если проблема встает со скоростью отработки скриптов - тогда проще всего сменить среду выполнения, применить C/C++ или Java. Разница в скорости между оптимизированным РHP с акселератором и между оптимизированным java или c-кодом на некоторых задачах может достигать двух порядков. Так что небольшая разница в скорости различных решений на базе PHP просто теряется, ее можно не учитывать.

 

[fixxxer]

>>Тогда в чем же смысл? Сделать так, чтобы работу по разработке шаблона просто не смогли отдать кому-то кроме разработчика?

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

если вот так вот взять и разделить (пример этой идеи в абсолюте - xslt), получится ситуация такая, что программер петя вот все написал, дескать я все заset()-ил а дальше трахайтесь как хотите, и вот верстальщик вася, допустим, ему надо нарисовать хитрую фигню в полторы колонки полукругом - и вот он сидит и трахается с этими xslt или смартями целый день и рожает простыню, а будучи вобщем то и не программистом роды выходят мучительные и рождается очередной уродец в виде шаблона, который через 5 секунд после открытия в редакторе хочется закрыть нафиг и больше не видеть. а вот с блицем он попросит программера петю - а вот раскидай там мне вот вот в эти итерации - и петя это сделает не напрягаясь, для него это работа на 30 секунд. разделение труда - это вовсе не значит, что "я свою часть сделал а ты теперь трахайся", взаимодействие всегда продуктивнее.

 

[AmdY]

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

 

[Gorynych]

тема вечная.

основные минусы "embeded html":
- доведение кода до полностью не читаемой "лапши";
- сложность правки / модификации дизайна
- практическая невалидность выходного html-кода (не надо расказывать сказки про валидный html через print'ы)
- невозможность использовать ресурс типа "верстальщик" (встроенный html это не адаптация, а полный перепер верстки в код скрипта)

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

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

 

[The employer]

Автор оригинала: fixxxer
>>Тогда в чем же смысл? Сделать так, чтобы работу по разработке шаблона просто не смогли отдать кому-то кроме разработчика?

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

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

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

Мы сталкивались на практике с необходимостью передачи работы неквалифицированным людям. Я уже где-то рассказывал об этом - был сделан SDK, инкапсулирующий в себе сложности криптопротокола, этот SDK имел крайне простой внешний интерфейс, с примерами использования на VB, готовыми для copy-paste.

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

Теперь с работой по верстке может справиться и не-программист.

В smarty естть все необходимое именно для такого подхода. А над blitz придется каждый раз писать обертку. Труд невелик, но смысл? Некоторый выигрыш в быстродействии?

Автор оригинала: fixxxer
а вот с блицем он попросит программера петю - а вот раскидай там мне вот вот в эти итерации - и петя это сделает не напрягаясь, для него это работа на 30 секунд. разделение труда - это вовсе не значит, что "я свою часть сделал а ты теперь трахайся", взаимодействие всегда продуктивнее.

Да кто бы спорил. Просто фраза "а вот с блицем..." говорит о том, что blitz призван заставить верстальщика обратиться за помощью к программисту.

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

Автор оригинала: fixxxer
Если верстальщик может попросить программиста сделать для него что-то, что облегчит его труд - так в чем проблема?

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

 

[grigori]

AmdY, если не брать active template, расскажи примеры большого количества логики в шаблонах
самое сложное, что было у меня - вывод календаря

-~{}~ 03.08.09 12:34:

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

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

Сменить процесс сложней, чем с нативными шаблонами, но не нужно.

Мы обсуждаем не инжиниринг бизнес-процессов, а существующие шаблонизаторы применительно к существующим стабильным процессам.
Эти бизнес-процессы включают не только разработку и общение кодера с верстальщиком, но и содержание 200 серверов, которых при переходе на блиц становятся 150.

 

[AmdY]

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

 

[grigori]

пэйджинг - постраничная разбивка? это делается через limit/offset в sql ...
формы и таблыцы рисовать плагинами смарти ... что-то я в этой жизни не понимаю

-~{}~ 03.08.09 12:44:

лементы зависящие от уровня доступа ... а это не if-else ?

 

[AmdY]

{pager type="sliding" obj=$list}

конфиг формы храню в yaml
{form obj=$form}
{form_error}
{form_label name="user"}:{form_field name="user"}<br/>
{form_label name="password"}:{form_field name="password"}<br/>
{form_field name="submit"}
{/form}

да, if со сложными условиями стараюсь убирать в блоки, привычка от xslt

triumvirat
я считаю, что экранирование - это не задача шаблонов, они у меня в конфигах форм и таблиц.

p.s. я ниразу не говорю, что это правильно, просто мне нравится делать так и не только в смарти. наезды на блитз тоже необоснованные, выбирая ту или иную либу человек делает осознаный выбор стиля. к цели можно идти разными путями, главное не выбирать тупиковые, типо xtemplate.

 

[Духовность™]

формы .... рисовать плагинами смарти ... что-то я в этой жизни не понимаю

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

 

[nerezus]

triumvirat
|escape для экранирования в смарти, escape() в пхп.
Для selected есть хелперы, которые хорошо себя чувствуют в шаблонах.

 

[grigori]

AmdY
праблем в том, что {form obj=$form} моя дизайнер/верстальщик ни разу не напишет
она пишет html+css, а потом copy-paste его в шаблоны

отдебажить свой css на {form obj=$form} для верстальщика нереально

-~{}~ 03.08.09 14:16:

>делать htmlspecialchars и selected - замучаешься
AJAX фореве

 

[stillwaiting]

Не встречал ни одного примера, где бы смарти выигрывал перед связкой PHP шаблоны + прямые руки. Мое ИМХО: начинающим в обязательном порядке нужно использовать smarty, т.к. это поможет понять ньюансы отделения логики от "дезигна". А когда эти ньюансы выявлены и осознаны- smarty больше не нужен.

А в то, что научить верстальщика писать

{$my_super_var|mySuperFilter}

намного сложнее, чем

<?=TemplFilters::mySuperFilter($templ['my_var']); ?>

- я не верю. Зато не нужно тащить ничего лишнего в проект.

 

[Духовность™]

stillwaiting
+100

 

[nerezus]

<?=TemplFilters::mySuperFilter($templ['my_var']); ?>

Тролль?
<?=mySuperFilter($my_super_var)?>