смарти в порядке — просто, например, я ему сообщаю кол-во запросов сделаных к базе, сколько расходовалось памяти, что было найдето в кеше а что нет — банальная статистика
проблема в том, кто на момент создания смарти у меня порой ещё «далеко не всё известно» :)
но вы согласны, что _нужно_ использовать конструктор? а то несколько выше меня в этом пытались разубедить
нет не странно — fetch в коде вызываю только для компиляции писем — там переменные окружения не нужны. все «подготовки блоков» и прочая фигня происходит в шаблоне с помощью плагинов смарти, на этот момент он уже получил все «стандартные» значения
то, что они там публичные — это историческая «проблема», чтобы новые версии Smarty работали в PHP4 :(
а вообще, в первой же главе оф.мануала рекомендуют наследовать класс
относительно геттеров и сеттеров — довольно много ошибок в приложениях именно из-за того что кто-то в команде разработчиков где-то в коде присваивает свои значения переменным объекта, а где-то в другом месте всё начинает косячить несмотря на то, что все assertions ведут себя хорошо… используя getters && setters можно быстро получить весь стек значений, найти место в коде где безобразничали и надругаться над обидчиком.
внутри фабрика подгрузит библиотеку и передаст в её конструктор все аргументы, а потом просто вернёт указатель на свежий объект
если же использовать для этого дела «stand-alone» функции, то с того момента, когда на проекте будет сидеть 30 девелоперов и 2 000 000 строк кода — то каждого нового члена команды будете обучать по несколько месяцев ну и так далее в этом же духе :)
лучще всё делать на объектах и полностью инкапсулировать их действия
штатные средства — какие например? я не видел у Smarty ни getter ни setter functions, более того, в конструкторе можно сделать ещё много чего полезного, оттуда и название — «конструктор» :)
штатный fetch я переопределяю в 100% случаев — типа сначала отдать smarty все «стандартные» переменные (типа путей и прочей херни), а потом уже вызывать родительский
class mySmarty extends Smarty{
public function __construct(){
//тут оверрайдим все дефольные настройки смарти
//во все пути можно так же фигачить массивы, они будут обрабатываться по-очереди пока там не будет найдек нужный файл
//ejoy
}
}
вообще я когда-то пришёл к такой же иделогии как и zerkms выше habrahabr.ru/blogs/php/60561/#comment_1654271
ведь в итоге НАМ главное за минимальные сроки заработать как можно больше :)
Прикольное решение ++
Я, правда, лет 5 назад выбрал другой путь:
— Контроллер даёт Smarty базовые данные (например список постов для блога)
— В самом шаблоне дизайнер можно «пропросить ещё» с помощью узконаправленных функция с параметрами, например захотелось мне список ссылок на все посты в календарике — пишу {load_calendar month=$month foo=bar bla=foo} — а со стороны смарти есть плагин, который запрашивает у БД эти данные и там же делаеть $smarty->assign… естественно всё это щастя можно обрамить блоком {cache}{/cache} и запрашиваться эти данные будут всего, например, раз в сутки :)
но вы согласны, что _нужно_ использовать конструктор? а то несколько выше меня в этом пытались разубедить
а вообще, в первой же главе оф.мануала рекомендуют наследовать класс
smarty.net/manual/en/installing.smarty.extended.php
относительно геттеров и сеттеров — довольно много ошибок в приложениях именно из-за того что кто-то в команде разработчиков где-то в коде присваивает свои значения переменным объекта, а где-то в другом месте всё начинает косячить несмотря на то, что все assertions ведут себя хорошо… используя getters && setters можно быстро получить весь стек значений, найти место в коде где безобразничали и надругаться над обидчиком.
Простите, наболело :)
public function display($template,$cacheID){
$this->assignDefaultVariables();
//...other userful stuff b4 display
return parent::display($template,$cacheID);
}
само приложение для генерации любой отдельно взятой страницы в любом случае вызовет только один раз display =)
$object->foo = 'bar'; //epic fail
$object->setFoo('bar'); //will survive
$smarty = $myFactory->cast('smarty',[arg1,[arg2],[argn]]);
внутри фабрика подгрузит библиотеку и передаст в её конструктор все аргументы, а потом просто вернёт указатель на свежий объект
если же использовать для этого дела «stand-alone» функции, то с того момента, когда на проекте будет сидеть 30 девелоперов и 2 000 000 строк кода — то каждого нового члена команды будете обучать по несколько месяцев ну и так далее в этом же духе :)
лучще всё делать на объектах и полностью инкапсулировать их действия
class mySmarty extends Smarty{
public function __construct(){
//тут оверрайдим все дефольные настройки смарти
//во все пути можно так же фигачить массивы, они будут обрабатываться по-очереди пока там не будет найдек нужный файл
//ejoy
}
}
вообще я когда-то пришёл к такой же иделогии как и zerkms выше habrahabr.ru/blogs/php/60561/#comment_1654271
ведь в итоге НАМ главное за минимальные сроки заработать как можно больше :)
Я, правда, лет 5 назад выбрал другой путь:
— Контроллер даёт Smarty базовые данные (например список постов для блога)
— В самом шаблоне дизайнер можно «пропросить ещё» с помощью узконаправленных функция с параметрами, например захотелось мне список ссылок на все посты в календарике — пишу {load_calendar month=$month foo=bar bla=foo} — а со стороны смарти есть плагин, который запрашивает у БД эти данные и там же делаеть $smarty->assign… естественно всё это щастя можно обрамить блоком {cache}{/cache} и запрашиваться эти данные будут всего, например, раз в сутки :)