Гуру, я не знаю что такое MVC в PHP, хоть и считаю себя опытным программистом. Объясните наконец!

[tz-lom]

rvolt
шаблон - это то, что прислал верстальщик, как только ты всавил туда <?=$var?> или {$var} - это уже view и это уже УГ, потому что появляется проблема программист-верстальщик. в идеале шаблоны должны оставаться неизменными и процес должен проходить так:

// controller
$this->getView()->set('var', $var);
$this->getViews()->render('template');
// view
$this->token('p#var', $this->get('var'))
// template
<p id="var">рыба верстальщика</p>

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

 

[Вурдалак]

AmdY, ты сам-то такой подход пытался использовать? Как циклы бы делал?

tz-lom, контроллера это не касается: вся эта логика с 'p#var' во каком-то view-объекте, смотри внимательнее.

 

[fixxxer]

rvolt
шаблон - это то, что прислал верстальщик, как только ты всавил туда <?=$var?> или {$var} - это уже view и это уже УГ, потому что появляется проблема программист-верстальщик. в идеале шаблоны должны оставаться неизменными и процес должен проходить так:

// controller
$this->getView()->set('var', $var);
$this->getViews()->render('template');
// view
$this->token('p#var', $this->get('var'))
// template
<p id="var">рыба верстальщика</p>

Идея хорошая, но парсить весь html вместо спецтокенов будет слишком накладно.

А так я как-то давно толкал идею, делать View в виде полноценного (ну почти) парсера в dom (который, в принципе, можно кэшировать) и сервер-сайд JS (который, в принципе, можно компилировать). Но это все будет тормозить конечно.

Будущее, короче, за вебсокетами и View на стороне клиента.

 

[symfo]

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

От всех идиотов не застрахуешься. Да и не нужно думать за всех, а уж тем более за говнокодеров, им никакой MVC не поможет, где "нагадить" они найдут.

Привык считать, что "ШАБЛОНИЗАТОР" - это "КОНТРОЛЛЕР" "ВИДА". Т.е. он управляет логикой построения готового отображения (HTML/XML/JSON...), а отдельный шаблон - это правило его построения.

Можно, конечно, сделать полностью свободные от управляющих команд шаблоны, вынеся все в контроллер. Но это уже будет конкретный перебор, т.к. в реальном проекте таких партиалов соберется туева хуча. Обычный select-input будет представлять собой 2 партиала: '<select name="{$selectName}">{$options}</select>' и '<option value="{$optionValue}">{$optionName}</option>'.
Т.е. создать дополнительный слой - View Controller, со своими классами управления, которые будут вызываться из Controller.

fixxxer, да да! Именно что-то подобное и приходит в голову .
Видел нечто подобное в каком-то AJAX-PHP модуле. Но отказался от его использования, т.к. показалось не очень удобным . Написал свой AJAX-контроллер, мне он более удобен, т.к. все приложение работает на AJAX (грузится только главная страница).

 

[Mols]

Парни, вы о чем вообще, а?

 

[craz]

Парни, вы о чем вообще, а?

действительно чеэт мы))) гоу бухать?)

 

[AmdY]

AmdY
ну и классика, покажи пример полосатой таблицы при таком подходе.

Всё таки более распространённый метод (УГ в твоём смысле) мне как-то больше нравится.

c 2003-го это css правило nth-child(even)

 

[AmdY]

fixxxer
если компиляция а-ля смарти, то никаких тормозов не будет, мы взяли php, взяли html, распарсили его сделали html вставки. всё, чего раньше не хватало - это лябда функции для нестандартных правил.

 

[Gas]

AmdY
подход вроде похож как в старом шаблонизаторе XTemplates, шаблон, view ?

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

 

[AmdY]

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

 

[Gas]

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

 

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

В php все нормально с шаблонами. Вы их просто делать грамотно не умеете.

 

[rvolt]

В php все нормально с шаблонами. Вы их просто делать грамотно не умеете.

Опытом не поделитесь? Если можно, то с краткими примерами.

 

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

http://pastebin.com/es5aKbKc

 

[craz]

http://pastebin.com/es5aKbKc

title низковато <?=$this->getHelper('Html_Title')->getHtml()?> подними его

 

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

title низковато <?=$this->getHelper('Html_Title')->getHtml()?> подними его

зачем?

 

[Adelf]

зачем?

наверно тебе это советует гуру SE-оптимизации

А ты слышал о таких вещах как master pages в ASP.NET или layouts в Kohana?
Почти у всех шаблонов у тебя наверняка много одинакового в начале и в конце.

 

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

А ты слышал о таких вещах как master pages в ASP.NET или layouts в Kohana?

нет.

Почти у всех шаблонов у тебя наверняка много одинакового в начале и в конце.

Это осознанная позиция. Всё, что в head - это не одинаковое и варьируется в зависимости от страницы.

Подвал подгружается через include-оболочку.

 

[Alien85]

http://pastebin.com/es5aKbKc

черт ногу сломит, непонятно, чему вы тут восхищаетесь?

 

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

черт ногу сломит, непонятно, чему вы тут восхищаетесь?

если отбросить некоторые хэлперы, которые я вас не обязываю реализовывать в своей шаблонизации, то что Вам непонятного?