вообще это решать вам, я б посчитал что это логика представления.
бизнес логика — это логика бизнес процесса, как настройка вывода влияет на бизнес процесс? я думаю никак. Но вообще какое-либо разделение всегда субъективно.
спасибо за внимание к моей персоне.
Мне кажется что вы как и другие люди (http://habrahabr.ru/blogs/php/45337/#comment_1146067)
путаете понятия «отделение логики от представления» от понятия «отделение бизнес логики от логики представления». Я не знаю, стоит ли просто вдаваться в этот спор сейчас, но подумайте сами, попробуйте принять в предположении что мои слова верны и подумать самостоятельно — уверен вы сможете посмотреть на проблему тогда по-другому.
Кому нужна цель исключить какую либо логику из шаблонов? для этого есть HTML, цель разделить логику на логику работы системы (функциональную) и на логику представления отображаемых данных. Если первая задача безсмыслена, то вторая осмыслена — она разграничивает ответственность, расслаивает систему, делая более доступными для восприятия ее абстракции.
Если вы не хотите априори понять эту мысль, то вы не поймете, но я старался.
н-дя. не конструктивно все, кроме утверждения: «отделение логики от представления — не аргумент вовсе.»
чтож я б с вами поговорил на эту тему (хотя ради чего, ведь вы и так все решили для себя), еслиб статья была посвящена шаблонизаторам вообще, а не конкретному.
тут скажу лишь, что я считаю, что вы заблуждаетесь и путаете поняние «отделение логики от представления» от понятия «отделение бизнес логики от логики представления». но доказать вам это сейчас не представляю возможным.
я вам ответил на 2 поста: «ну логика на уровне ребенка» имею виду логику, представленную в шаблоне. Странно, что вы это приняли на свой счет, надеюсь недоразумение после моего пояснения разрешено?
Отделением логики от представления
во первых делает.
во вторых решает кучу фоновых задач: кеширование, упрощение синтаксиса, упрощает отладку, короче решает типичные задачи
можно тока тут она делается на уровне синтаксиса.
встречаются, не часто, но есть.
цифр не дам, потому что нужно специально заняться тестированием, а на это щас нет времени
интересная точка зрения, я б сказал гениальная в своей темноте, чтож не буду вас разубеждать, раз более 2-х милионов пользователей Смарти вас не убедило.
так вообще все это слова, а на практике люди делают выбор один раз и на долго, я вот, например, однажды принял смарти со всеми косяками, а щас вот для себя выбрал квик. и теперь больше не буду об этом думать, а тут так… диалоги, флуд.
чтоб квик обогнал php native нужно найти пример когда большое кол-во параметров будет всегда одинаково. В частности сейчас обсуждалась возможность условной перкомпиляции, если она будет введена, то квик будет обгонять php native в большем кол-ве случаев
пример, когда код, созданный квиком, выйграет:
{_for start=0 step=1 loop=1000 value=$i1}
{_for start=0 step=1 loop=1000 value=$i2}
{_$i1+$i2}
{/}
{/}
вообще это другая парадигма. xlst это метод преобразования и трансформирования потока данных. Шаблонизатор же в классическом понимании дает возможность работать вообще с выводом информации. Так, например, утверждение, что шаблон не может запросить необходимые для его работы данные ложно. Ровно как и ложно утверждение что логика запрещена в шаблонах. Лично мне не прижился xslt в чистом виде, хотя я знаю ребят, которые сделали успешные бизнес-проекты (UMI.CMS, например, там вся цмс рассматривается как донор XML данных), поэтому я не могу сказать уверенно и провести хоть как-то адекватное сравнение.
ну кстати у квики защита от дурака имеется, так, например к использованию разрешены функции, которые не меняют состояние внешних источников, так что всей идеологии въювера он отвечает полностью, ну а навредить можно можно на нем не больше, чем на смарти. Как говорится есть бесконечное богатое множество способов изгадить хорошую задумку.
бизнес логика — это логика бизнес процесса, как настройка вывода влияет на бизнес процесс? я думаю никак. Но вообще какое-либо разделение всегда субъективно.
Мне кажется что вы как и другие люди (http://habrahabr.ru/blogs/php/45337/#comment_1146067)
путаете понятия «отделение логики от представления» от понятия «отделение бизнес логики от логики представления». Я не знаю, стоит ли просто вдаваться в этот спор сейчас, но подумайте сами, попробуйте принять в предположении что мои слова верны и подумать самостоятельно — уверен вы сможете посмотреть на проблему тогда по-другому.
Кому нужна цель исключить какую либо логику из шаблонов? для этого есть HTML, цель разделить логику на логику работы системы (функциональную) и на логику представления отображаемых данных. Если первая задача безсмыслена, то вторая осмыслена — она разграничивает ответственность, расслаивает систему, делая более доступными для восприятия ее абстракции.
Если вы не хотите априори понять эту мысль, то вы не поймете, но я старался.
чтож я б с вами поговорил на эту тему (хотя ради чего, ведь вы и так все решили для себя), еслиб статья была посвящена шаблонизаторам вообще, а не конкретному.
тут скажу лишь, что я считаю, что вы заблуждаетесь и путаете поняние «отделение логики от представления» от понятия «отделение бизнес логики от логики представления». но доказать вам это сейчас не представляю возможным.
во первых делает.
во вторых решает кучу фоновых задач: кеширование, упрощение синтаксиса, упрощает отладку, короче решает типичные задачи
встречаются, не часто, но есть.
цифр не дам, потому что нужно специально заняться тестированием, а на это щас нет времени
чтоб квик обогнал php native нужно найти пример когда большое кол-во параметров будет всегда одинаково. В частности сейчас обсуждалась возможность условной перкомпиляции, если она будет введена, то квик будет обгонять php native в большем кол-ве случаев
пример, когда код, созданный квиком, выйграет:
{_for start=0 step=1 loop=1000 value=$i1}
{_for start=0 step=1 loop=1000 value=$i2}
{_$i1+$i2}
{/}
{/}