Так и не понял. Чем вот это

плюс


Лучше такого



или вот такого



Ну, а если посмотреть на циклы в Смарти.... то все становится еще веселее.

Удобочитаемость? Нет.
Скорость? Нет.
Скажите кеширование? Так, извините меня, кеширование вещь в себе, и с шаблонами связана слабо.

Вот и не понятно мне, чем же лучше?

Добавлено через 9 минут и 9 секунд

IMO - Шаблоны и шаблонизаторы отзвуки тех далеких времен, когда MVC или понимание о правильном разделение логики-представления в PHP практически не существовало.
Как результат велосипеды слабо повышающие уровень абстракции.

Тот же Смарти... Мне сложно понять, почему не принять правило что все входящие данные должны обрабатываться следующим образом (это если без ООП)


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

хм. я н говорил конкретно про СМАРТИ. 

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

псевдоязык того же СМАРТИ, раз уж про него(с XSLT практически не знаком, потому про него говорить не буду) предполагает вполне определенную область видимости. нет, конструкция assign тоже есть, но неудобство(как ті сам заметил) такой конструкции позволяет надеяться: переменые будут иметь однозначные и определенные в любом месте шаблона значения. вариации на тему переменных переменных и выполнение функции по её имени в виде строки в произвольной переменной если не улучшают стиль кода, упрощают отладку.
я бы провел аналогию с C#  и автоматического управления памятью, против С++ с ассемблерніми вставками и винегретом ссілок и указателей.

смотря какой код.

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


ой, обобщать не надо. HTML-вставки любой РНР-скрипт превращают в шаблон.

Добавлено через 2 минуты и 40 секунд

фи. у меня это выглядело бы так:

наверное, ни черта ни понятно в сравнении с 

т.е. проблема в инкапсуляции? я правильно понял?

Так и заводи отдельный массив/коллекцию/модель данных для вывода
и тогда будет




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

У PHP пока еще не тот уровень абстракции, чтобы были эффективными такие финты ушами. Можно, прекрасно можно... но кто сказал что это будет лучше?
Чем этот язык и специальные вставки будут отличаться от простейшего PHP синтаксиса?
Да ничем. Кроме лишней прослойки, которая в итоге дает сомнительные выгоды (в виде простоты и понятности). Мы ничего не получаем.
Я думаю, проще/дешевле и быстрее будет договориться о корпоративных стандартах кодирования... Получим тот же эффект.

Я вот в свое время, слишком доверял одному разработчику  Теперь приходится вилизывать перлы из кода.
В виде расставленных куда ни попадя @, бросания exception там, где достаточно просто вернуть false (например при пустой выборке из базы) и т.д.

это


поправил

Как ты считаешь, это сильно отличается от твоего варианта ниже?



Заметь, в моем случае мы не учим "новые" операторы {} | 

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

тебя смущает инициализация переемнных в пределах логики отображения? т.е.. к примеру, порядковые номер строки в таблице надо генерировать в пределах модели? создавать сущность "счетчик строки для таблицы №3"? сама по себе инициализация тоже ни плоха, ни хороша. но когда бы объявляем явно

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

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

Добавлено через 4 минуты и 45 секунд

зато надо знать, что 

вернет false не только для значения false, но и для неустановленной переменной, числа 0, пустой строки, пустого массива и т.д.

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




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


Ты невнимательно смотрел мое предложение
договоритесь о двух вещах.
1. массив $DATA_FOR_TEMPLATE может только читаться во всех представлениях.
2. Вызов или include всех представлений инкапсулируй в одной единственной функции
Все.



Если разработчики не могут придерживаться этих 2х простых правил. То тогда кто тебе сказал, что при своих умственных способностях они разберутся в Smarty?

так потихоньку переходим к созданию CMS с разделением модулей согласно схемы  MVC: сначала обрабатываются все модели, наполняя $DATA_FOR_TEMPLATE, потом выполняются код формирования представлений. 

"всех" - это значит "всех", или "для каждого"? второе логичнее, потому как позволяет просто реализовать кеширование.
в любом случае, необходима система кеширования. тем более, если $DATA_FOR_TEMPLATE неизменен, то обращение к одному и тому же представлению должно возвращать одни и те же данные(если содержимое детерменизировано). так мы наворотим тот же "шаблонизатор", но только на РНР + вызов специализированных функций. Как минимум, по сложности это не будет отличаться от спецвставок в HTML в том же СМАРТИ. Потому, как на меня, вариант с РНР ничем не лучше. В принципе, и не хуже. Разве что вопрос ограничений, о которых мы с тобой уже страницу говорим, в одном случае - вопрос договоренности, в другом - данность.

Это самый разумный вариант. Можешь предложить что-то лучшее?


Конечно для каждого. Функция может быть универсальной.
Всех сразу - не выгодно 


Не совсем так, оно детерменизировано в данном текущем вызове. Кто-то обещал, что оно будет таким же при следующем вызове?


Бритва Оккама - не плодите сущностей сверх необходимого...
Еще один язык поверх PHP - на мой взгляд, пока это неразумно.

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

речь только о том, что другой, отличный от РНР синтаксис?
или о том, что CMS по модели MVC вносит свою структуру функци/объектов/классов и свою логику - забыли? или эти сущности под бритву Оккакма не попадают?  

Добавлено через 4 минуты и 22 секунды

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

Подсветка - часть представления.
Выбор случайного элемента - часть модели.
Я так считаю. 

Модель/Контроллер определяет, что выводить. Представление - как выводить.


Совершенно верно.

Вот смотри, сейчас для нормальной работы нужно знать 4 вещи

SQL, PHP, HTML, JS. (можно обойтись без последнего, но сейчас не модно, да и впрочем не нужно обходиться).

Ты предлагаешь добавить 5й элемент. Псевдоязык дополнительной разметки.
Мне это не нравится потому что у нас уже есть 2!!! динамических скриптовых языка, которые полностью покрывают все область которую можно предумать для этого псевдоязыка.

Я понимаю, была бы логика, если бы программа была на чем-то строгом и тяжелом в виде Java, C/C++ - Тогда да смысл упростить и облегчить есть (ввести легковесный динамический скрипт для логики разметки, хотя чем не угодил в таком случае XSL?)... В нашем же случае - не вижу смысла.


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

Добавлено через 2 минуты и 41 секунду

Вообще-то,
тут может быть ситуация размазанности функций Контроллера.

Когда Модель будет представлять не только коннект к данным, но и существенную часть логики.
Это то, что я хочу сейчас реализовать - мета-модель с включенной бизнеслогикой, которая будет объединять в себя более мелкие и простые аксессоры к данным.

а представление тоже может распадаться на два уровня.

ога. какие программисты бедные и несчастные 
т.е. если потребуется использовать mathML или SVG - люди начнут падать в обморок?
я тут вижу: два императивных языка(php и js), причем один на стороне клиента, другой на стороне сервера; один - декларативный(sql) и один язік разметки(догадйтесь сами). дополнительный язык разметки при наличии справочника по основным конструкциям не должны смутить при любом раскладе. так же, как не должен вызвать конвульсий переход на VBScript или Perl. Да, другой синтаксис. Некоторые(совсем некоторые) вещи сделаны по-другому. но подход к программированию тот же. только синтаксис другой.

Это сообщение отредактировал(а) skyboy - 2.8.2008, 22:39