MACRO - стотысячная попытка сделать новый PHP шаблонизатор

itprog

Cruftsman
dark-demon
это порочная практика. view не должно вызывать controller. ни в явном, ни в косвенном виде.
а можно это как-то аргументировать, показать конкретные примеры почему это плохо?
 

dark-demon

d(^-^)b
pachanga, ага :)

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

dark-demon

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

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

korchasa

LIMB infected
Автор оригинала: itprog
а можно это как-то аргументировать, показать конкретные примеры почему это плохо?
Лишняя связь между классами, со всеми отсюда вытекающими.
 

itprog

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

Другие аргументы тоже не убедительны, т.е. либо есть хорошие решения, либо такое нужно в 99% случаях

-~{}~ 14.10.07 21:26:

korchasa
Мне кажется что dark-demon лучше понял вопрос...
 

dark-demon

d(^-^)b
itprog, ну, например, модули "админ панель" или "статистика формирования страницы" - должны ли они не зависеть от других модулей?
 

pachanga

Новичок
...и так топик ушел окончательно в оффтоп.

Кто-то что-то еще может добавить собственно по теме треда?
 

dark-demon

d(^-^)b
> Если исключается какой то модуль из страницы, то это уже можно считать другим скином.

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

ONK

Пассивист PHPСluba
Добавлю свой мало содержательный пост.

ИМХО - ненужная штуковина. Разработчик будет с ней носиться как с чемоданом без ручки (и нести не удобно и выкинуть жалко).
 

ustas

Элекомист №1
dark-demon
представь что тебя в очередной раз послали в бан, забань себя на недельку, развёл флуд.


pachanga
скачал с https://svn.limb-project.com/3.x/trunk/limb/macro, но не нашел реализации tree .
как реализовать хочешь ?
------------------------------
{{tree *****}}
html
{{call tree *****}}
html
{{/tree}}
------------------------------
во внутреннем представлении функция, или есть другие идеи?
 

pachanga

Новичок
pachanga
скачал с https://svn.limb-project.com/3.x/trunk/limb/macro, но не нашел реализации tree .
как реализовать хочешь ?
Посмотри плиз реализацию {{list}}, примерно тот же подход будет использоваться и здесь: родительский макрос {{tree}} будет на этапе компиляции находить своих детей {{tree:item}}, {{tree:branch}}, текстовые блоки и генерировать соотв. PHP код. Весь вопрос в том, получиться ли сделать реализацию итеративной без рекурсии или нет... Я постараюсь сделать на неделе.
 

korchasa

LIMB infected

Автор оригинала: dark-demon
ещё ни разу не использовал :)
[offtop]Забавно, когда человек, советует технологию, которую ни разу не использовал, и соответственно не имеет представления о ее минусах. Тут так принято?[/offtop]
 

AP

Новичок
pachanga, ну наконец то можно взглянуть на MACRO.... Какие зависимости влечёт за собой использоване MACRO?
 
Сверху