PHP: про eval и его друзей :-)

Crazy

Developer
Автор оригинала: Mammoth
Наверное мне повезло, и я сразу сел за изучение Smarty. По крайней мере не буду врать - сравнивать этот энджайн мне не с чем. Но те примеры, которые ты привел, относительно него абсолютно беспочвенны.
Ну почему же "беспочвенны". Все очень хорошо сработало. Я имел намерние показать, как уже было сказано выше, что чем функциональнее средство, тем сложнее у него синтаксис.

Я дал несколько примитивнейших примеров -- ты нашел, как они реализуются в одном из энжинов. Прекрасно. Но что же мы видим? Синтаксис уже не ограничен банальным {VAR}, не правда ли? Мы уже получили сложный синтаксис для макроподстановок и условные операторы.

Уже на смешных примерах мы прошли пол-пути до синтаксиса PHP. Вместо самоочевидного {VAR} мы уже получили свой язык, сравнимый по сложности с PHP.

Пока все верно?
 

Crazy

Developer
Автор оригинала: vano
Crazy, а ты не мог сразу сказать, какие шаблоны ты используешь? Нет, нужно было пустой флейм устроить...

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

Однако Mammoth, к примеру, ведет дискуссию вполне аргументированно и лично мне его ответы интересны. Тебе -- нет?

А что использую я... Разве выше это не было сказано?
 

vano

Guest
Автор оригинала: Crazy

Ну почему же "беспочвенны". Все очень хорошо сработало. Я имел намерние показать, как уже было сказано выше, что чем функциональнее средство, тем сложнее у него синтаксис.

Я дал несколько примитивнейших примеров -- ты нашел, как они реализуются в одном из энжинов. Прекрасно. Но что же мы видим? Синтаксис уже не ограничен банальным {VAR}, не правда ли? Мы уже получили сложный синтаксис для макроподстановок и условные операторы.

Уже на смешных примерах мы прошли пол-пути до синтаксиса PHP. Вместо самоочевидного {VAR} мы уже получили свой язык, сравнимый по сложности с PHP.

Пока все верно?
Товарищь, тебе на парсер.ру надо! :)
 

Mammoth

Guest
Автор оригинала: Crazy

Ну почему же "беспочвенны". Все очень хорошо сработало. Я имел намерние показать, как уже было сказано выше, что чем функциональнее средство, тем сложнее у него синтаксис.

Я дал несколько примитивнейших примеров -- ты нашел, как они реализуются в одном из энжинов. Прекрасно. Но что же мы видим? Синтаксис уже не ограничен банальным {VAR}, не правда ли? Мы уже получили сложный синтаксис для макроподстановок и условные операторы.

Уже на смешных примерах мы прошли пол-пути до синтаксиса PHP. Вместо самоочевидного {VAR} мы уже получили свой язык, сравнимый по сложности с PHP.

Пока все верно?
Не совсем. Синтаксис по сравнению с конструкцией {VAR}, действительно несколько более развит. Но не настолько, чтоб можно было говорить о новом ПХП. Если желаешь, остановимся на синтаксисе отдельно, а пока отвечу более концептуально.

Главное, чего можно достичь при использовании Smarty - это то, что дизайнер не правит код. При всем при этом дизайнер имеет широчайшие возможности по написанию именно представления сайта.

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

Сможет ли это обеспечить твой "гибкий" "кусочный" подход?
 

Crazy

Developer
Автор оригинала: Mammoth
Главное, чего можно достичь при использовании Smarty - это то, что дизайнер не правит код.
Не правит код чего?

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

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

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

Crazy

Developer
Автор оригинала: Mammoth
Сможет ли это обеспечить твой "гибкий" "кусочный" подход?
Не очень понятно, почему мой подход ты называешь кусочным... Ok, о моем подходе подробнее:

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

2. Де-факто большинство верстальщиков либо уже знают PHP, либо обучаемы в достаточной степени, чтобы использовать несколько показанных им синтаксических конструкций.

3. Использование PHP для кодирования представления отвечает философии языка и полностью поддержано как со стороны синтаксиса PHP, так и со стороны энжина.

Собственно, особенностью такого подхода является то, что мы ограничиваем верстальщика прежде всего не технически, а административно. :)

Есть, разумеется, и технический подход к ограничению -- test before code. Подробности интересны?
 

tony2001

TeaM PHPClub
>Т.е. ты предлагаешь засунуть в код задание ПРЕДСТАВЛЕНИЯ?
>Хм... Что там чуть выше писали о поддержке кода?
зачем же ?
этот конкретный случай (вывод числа с разделителями) - это не дизайн, это данные. вот данные пихаются в шаблон посредством кода. задача шаблона - обеспечить оболочку этих данных и ее легкую смену.

>Уже на смешных примерах мы прошли пол-пути до синтаксиса
>PHP. Вместо самоочевидного {VAR} мы уже получили свой
>язык, сравнимый по сложности с PHP.
>Пока все верно?
я не работал со Смарти.
хотя слышал не очень лестные отзывы по поводу его замороченности.
повторяю еще раз для тех, кто не понял:
у меня (не знаю как у вас) в шаблонах НЕТ кода сложнее %var%.
засчет этого все очень просто и ясно.
 

tony2001

TeaM PHPClub
никто не против, если мы в Оффтоп перейдем ?
думаю, что никто.
 

Mammoth

Guest
Автор оригинала: Crazy
Не правит код чего?

Повторюсь: я разделяю не "код шаблонов" и "код PHP", а "описание логики" и "описание представления". По большому счету мне безразлично, на чем они описаны. Важно, чтобы эту работу могли выполнять разные люди. Важно, чтобы шаблоны и код можно было повторно использовать по отдельности.
Давай тогда определимся насчет терминов: "код" эквивлентно "логике", а "шаблон" - "представлению". По этому вопросу, на мой взгляд, не должно быть никаких разногласий.

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

В приведенных выше мной примерах реализации шаблонов я имел в виду, что "раскрашиванием" и "переводом в верхний регистр" занимается именно дизайнер. Т.е. дизайнер занимается ХТМЛ'ем и тегами Smarty, а программист - обработкой данных.

Автор оригинала: Crazy
Я вполне согласен что использование шаблонных энжинов -- того же Smarty -- решает эту проблему. Но любое решение имеет цену и нужно отдавать себе в этом отчет, а не заниматься самообманом, как мы видели в некоторых письмах выше. Действительно, любой шаблонный энжин -- это прежде всего ограничение функционала.
Вот не вижу я в упор ограничения функционала, хоть убей! Я тебя поэтому и просил привести такие примеры, которые бы не могли бы быть реализованы "шаблонным способом"...

Автор оригинала: Crazy
Мы сознательно отбираем у верстальщика те функции, пользование которыми вредно (вот почему я никогда не буду добровольно использовать parser в своих проектах). Но принимая решение об отборе тех или иных функций мы всегда руководствуемся некоторым предшествующим опытом, который в некотором очередном проекте может быть недостаточен. Так, вполне нормальна ситуация, когда в используемом энжине вдруг не оказывается той или иной нужной фичи -- сам наталкивался на это не раз.
Мы ничего ни у кого не отбираем. Просто четко разграничиваем область работы дизайнера и программера. Сам по себе Smarty очень небольшой и прост в усвоении, но он поддерживает добавление "фич" с помощью плагинов (функций на ПХП). Т.е. если дизайнеру что-то надо, он не стесняясь придумывает "фичу", а программер ее реализует.
 

Crazy

Developer
Автор оригинала: tony2001
>Т.е. ты предлагаешь засунуть в код задание ПРЕДСТАВЛЕНИЯ?
>Хм... Что там чуть выше писали о поддержке кода?
зачем же ?
этот конкретный случай (вывод числа с разделителями) - это не дизайн, это данные.
Вот в этом и заключается принципиальное различие наших взглядов. Для меня 12345 -- число. А "12,345", "12 345", "$12345" -- это представление. Для меня вполне нормальна ситуация, когда результат одного и того же логического блока в русскоязычном шаблоне отображается как "12 345", а в англоязычном -- "12,345" -- в соответствии с региональными правилами формирования внешнего представления.
 

Crazy

Developer
Автор оригинала: Mammoth
Давай тогда определимся насчет терминов: "код" эквивлентно "логике", а "шаблон" - "представлению". По этому вопросу, на мой взгляд, не должно быть никаких разногласий.
Отнюдь. Шаблоны -- лишь один из способов формирования представления. Хоть в жестком понимании -- хоть в гибком.

Вот не вижу я в упор ограничения функционала, хоть убей! Я тебя поэтому и просил привести такие примеры, которые бы не могли бы быть реализованы "шаблонным способом"...
Ok. Я вижу, мы действительно готовы перейти к более забавным примерам. Итак, начнем усложнять:

Код:
<table border=1>
  <tr valign=top>
    <td>Foo</td><td rowspan=8>Some comment</td>
  </tr><tr>
    <td>Bar</td>
  </tr><tr>
    <td>Buzz</td>
  </tr><tr>
    <td>Quixx</td>
  </tr><tr>
    <td>---</td>
  </tr><tr>
    <td>111</td>
  </tr><tr>
    <td>222</td>
  </tr><tr>
    <td>333</td>
  </tr>
</table>
Мы видим здесь две последовательности, записанные в левой колонке и разделенные отдельной строкой. Справа -- единая колонка с некоторым текстом.

Вопрос: как это реализуется на Smarty?
 

tony2001

TeaM PHPClub
>Для меня вполне нормальна ситуация, когда результат одного и
>того же логического блока в русскоязычном шаблоне
>отображается как "12 345", а в англоязычном -- "12,345" -- в
>соответствии с региональными правилами формирования
>внешнего представления.
когда у меня встанет подобный вопрос - допишу соотв. функциональность к шаблонам. можно юзать Смарти, но как-то не хочется разбираться в монстрических созданиях...
 

Crazy

Developer
Автор оригинала: Mammoth
Т.е. если дизайнеру что-то надо, он не стесняясь придумывает "фичу", а программер ее реализует.
Это требует тесной связи между верстальщиком и программистом. А установления тесных связей там, где без них можно было бы обойтись, лучше таки избегать.
 

tony2001

TeaM PHPClub
>Вопрос: как это реализуется на Smarty?
будь уверен, реализуется.

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

Crazy

Developer
Автор оригинала: tony2001
когда у меня встанет подобный вопрос - допишу соотв. функциональность к шаблонам.
См. выше про тесную связь. Этот подход идеален пока программист и верстальщик -- одно лицо. И чем дальше их растаскиваешь -- тем хуже оно работает.

Пример: имеет код, написанный российским программером, который в школе учил немецкий. И имеем финского локализатора, которому для перевода интерфейса на финский потребовалась новая фича. Финн знает английский. Вопрос: сколь плодотворно будет их общение через переводчика? :)
 

Crazy

Developer
Автор оригинала: tony2001
>Вопрос: как это реализуется на Smarty?
будь уверен, реализуется.
Практически верю. Но хочу код. Ибо вопрос направлен не на установление потенциальной реализуемости. :)

разговор собственно начался с чего:
есть шаблоны
есть пхп код
Разговор начался с определения, кто что понимает под шаблонами. Я объясняю, почему мне удобно иметь в шаблонах PHP-код. Ты пытаешься мне объяснить, почему мне это должно быть неудобно. :)
 

tony2001

TeaM PHPClub
>Это требует тесной связи между верстальщиком и программистом.
бывает по-другому ?
программер делает одно, верстальшик - другое, дизайнер - третье ??

>См. выше про тесную связь. Этот подход идеален пока
>программист и верстальщик -- одно лицо.
нет.
этот подход идеален тогда, когда подобная функциональность может быть или уже реализована в шаблонах.
 

tony2001

TeaM PHPClub
>Ты пытаешься мне объяснить, почему мне это должно быть
>неудобно.
ну зачем же.
по большому счету мне все равно как у тебя это реализовано.
ты спросил что мне не нравится в этом подходе - я попытался объяснить.
 

Crazy

Developer
Автор оригинала: tony2001
>Это требует тесной связи между верстальщиком и программистом.
бывает по-другому ?
программер делает одно, верстальшик - другое, дизайнер - третье ??
Именно. А отдельная спецификация согласует их действия.
 
Сверху