внутри фабрика подгрузит библиотеку и передаст в её конструктор все аргументы, а потом просто вернёт указатель на свежий объект
если же использовать для этого дела «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} и запрашиваться эти данные будут всего, например, раз в сутки :)
все эти процессы автоматизируются, ровно как и апдейт структуры бд.
говорю из опыта обновления софта _одновременно_ на 8 продакшн серверах (у svn) в этом смысле божественно много настроек; у приличных людей, кстати, вся статика живёт отдельно от кода
во всем проектах где я участвовал на продакшн машинах было
svn co /branches/stable/
все разработки ведуться в отдельных ветках, в stable только багфиксы — они раз в сутки «поднимаются» в другие ветки, таким образом обновить продакшн можно просто через
$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} и запрашиваться эти данные будут всего, например, раз в сутки :)
говорю из опыта обновления софта _одновременно_ на 8 продакшн серверах (у svn) в этом смысле божественно много настроек; у приличных людей, кстати, вся статика живёт отдельно от кода
svn co /branches/stable/
все разработки ведуться в отдельных ветках, в stable только багфиксы — они раз в сутки «поднимаются» в другие ветки, таким образом обновить продакшн можно просто через
svn update