а идея с плагином ИМХО стоящая.

#39921 Uch:

Например, вставлять одинаковые текстовые блоки в тексты страниц на мультиязычном сайте.
 

или вставка в текст страницы блоков в зависимости о геолокации.

Как раз обработки тегов в странице очень не хватает.

в том, что я тестил - не работает tpl_debug

Ага есть такое

Для включения дебага в плагине chunks в файле global добавить разрешение

было

// -- For development brunch only, remove on production -----
XTemplate::init(array(
	'cache'        => false,
));

сделать

// -- For development brunch only, remove on production -----
$tpl_debug = cot_import('tpl_debug','G','BOL');

XTemplate::init(array(
	'cache'        => false,
        'debug'        => $tpl_debug,
        'debug_output' => $tpl_debug
));

Либо вообще  это удалить.. это временное отключение кэша на время разработки

Те же самые, что и к чанкам :)

Тогда спрошу по другому — для каких целей?
Приведи пример реального использования — опиши целиком: что за сайт, кто размещает материал, как будет использован этот механизм. 

Это не праздный вопрос — для реализации той или иной «хотелки» надо понимать «для чего», а для правильной реализации «хотелки» понимат еще и «как».

А в тексте страницы, который мы формируем в текстовом редакторе, можно будет использовать эти чанки?

Нет, у механизма чанков другие задачи. А самое главное другой механизм. Чанки это составляющая механизма шаблонов. Они «привязаны» к шаблону и парсятся и кешируются вместе с ним. Чанки это механизм гибкого расширения шаблонов.

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

Спасибо, работает! Воистину очень удобно получилось!

Так для этого все и делается))) 

Обновил репозиторий — были ошибки в коде (бессонный ночи дают о себе знать), из за которых, параметры брались не из той переменной. Проверьте.

Спасибо, работает! Воистину очень удобно получилось!

файл должен быть такой chunks.имя_чанка.tpl или chunks.имя_чанка.подимя.tpl  пример : chunks.header.tpl или chunks.header.menu.tpl

Вызов чанка {CHUNK:имя_чанка}  для примера выше это будет {CHUNK:HEADER} или {CHUNK:HEADE.MENU}

2) вызов с параметрами:

По месту положения параметра.

вызов чанка в основом шабллоне {CHUNK:name param1,param2}  получение параметров в файле чанка: {$0} - param1 и {$1} - param2

По имени параметра

вызов чанка в основом шабллоне {CHUNK:name param1=123,param2="Hello"}  получение параметров в файле чанка: {$param1} - param1 и {$param2} - param2

Использование PHP функций и переменных в параметрах.

{CHUNK:name PHP.usr.name}  в чанке параметр {$0} будет иметь имя пользователя.

{CHUNK:name PHP|cot_func()}  в чанке параметр {$0} будет иметь результат выполнения функции cot_func()

{CHUNK:name PHP.var|cot_func($this)}  в чанке параметр {$0} будет иметь результат выполнения функции cot_func($var)  т.е. с передачей параметра var в функцию.

Пока версия тестовая, и возможно все поменяется..

1) Установил плагин и заменил файл шаблонизатора.

2) В теме сайта создал шаблон chunks.hello.tpl с таким содержимым: 

Здравствуйте, <b>{$name}</b>!

В шаблоне объявил чанк таким образом: 

{CHUNK:HELLO name=Bob}

Всем кому интересна идея чанков... уже можно ее потестить. https://github.com/macik/cot-chunks.

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

это пока не релиз а beta версия... пишите если что-то обнаружится..

А чем не устраивают колбеки для этих целей?

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

главное иметь возможность использовать переменные текущего шаблона. Если формировать чанк заранее, то в нем невозможно будет указать многие Теги т.к. они еще не определены

Дык, так у меня похожая ситуация, так выглядит меню юзера:

[item, класс=меню в линию,alt=]
{{HEADER_USER_ADMINPANEL}}
•
{{HEADER_USERLIST}}
•
{{HEADER_USER_PROFILE}}
•
{{HEADER_USER_PFS}}
•
{{HEADER_USER_PMREMINDER}} 
[/item]

но, как только попадает в область видимости, то сразу  Users•Profile•My files•No private messages  а может и на другом языке или с картинками. Как раз, я еще не знаю, что там дальше определиться.

Но вы, в своем правы, конкретное использование опредеяет интстумент..Как я смог бы использовать чанки, я не знаю. Не знаю потому, что надо пробовать, смотреть. С ходу такое я не буду отбрасывать, это глупо. Вы долго продумывали это, вам известны подводные камни и практика применения. У меня планируется много новых инструментов, некоторые отработаны, другие ждут очереди, например

Другой, замечательной стороной такого решения является то, что можно содержанием страницы «расписать» содержимым альтернативы. Например, довольно часто, встречается такая ситуация, что необходимо указать дополнительные сведения об авторе. Google+ Привязка к профилю Google+ с помощью атрибута rel="author", требуется подтверждение авторства, необходима фотография с определяемым на ней человеческим лицом. Конечно, определение можно вставить в персональные данные юзера...но такого не предусмотрено, а часто и не положено. Когда юзер вносит что-либо в таблицы баз, очень велика вероятность попытки взлома сайта, поэтому фильтры CMF Cotonti не дадут ввести иную информацию, кроме как простой текст без тегов. Каждое такое внесение имеет, кроме того, ограниченную длину и не предусматривает механизма применения RESS технологии.

В механизмеMobiCotдля альтернатив можно ввести в тексте подробное описание для тега.

Так, для вывода сведений об авторе вGoogle+, может быть переопределен тегPAGE_AUTHOR:

[-newpage=PAGE_AUTHOR]

[title]Сведения об авторе[/title]

[url=https://plus.google.com/102142376663746186500?rel=author]Sergey Kocha[/url]

Как вы поняли, из примера, текст страницы, в этом случае, заменяет содержание тега PAGE_AUTHOR, Так как страница теневая (-newpage), она будет использоваться только для переопределения тега PAGE_AUTHOR.

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

Описанный вариант уже реализован в «alot-n-tags». Вот только от этого мы как раз и стараемся уйти, т.к. в чанках хочется использовать полный функционал шаблонов, а главное иметь возможность использовать переменные текущего шаблона. Если формировать чанк заранее, то в нем невозможно будет указать многие Теги т.к. они еще не определены. 

Тег это некая единица информации имеющая свое имя. Пример тега: {{PAGE_SHORTTITLE}}

А чем не устраивают колбеки для этих целей?

$t->assign(array(
    "ТЕГ_ЧАНК_N" =>$t_чанк_N->text("MAIN_ЧАНКА")

хоть где, так как экземпляр класса  $t_чанк_N глобален. Тогда как  очередное

$t = new XTemplate($mskin); 

убивает старое $t.Теоретически, я бы мог свой шаблон таким образом грузить прямо, со своей именнованой страницы статьи, и даже не придется шаблонизатор переделывать, достаточно, такую страницу помещать в файл шаблона плагином. Хотя можно и обойтись всем содержанием статьи. Но тут, надо думать о защите. Или иметь специальные системные и недоступные всем страницы, а  то взломают сайт. Такая страница или оганизовывала бы файл шаблона, или меняла его. Это всегда единожды.

---

Что касаемо вставить тег для этого у меня есть такая штучка Тег-процессор:

Тег это некая единица информации имеющая свое имя. Пример тега:
 

где в фигурных скобках, которые обозначены как {{ и }} указано имя тега.

Процесс формирование какого либо параметра на ресурсе в CMS Cotonti происходит по следующему сценарию:на серверной части формируются теги. Далее теги вставляются в темплейт. Полученный результат отображается на экране.

Для наиболее полного использования плагина Mobile web: slots необходима вставка тегов. Ранее приведенный тег {HEADER_NOTICES} формируется модулем header.php. Этот тег предназначен для вывода сообщение юзеру, например о письмах, полученных для него. Когда формируется меню, в котором используется этот тег, то встает вопрос, а как быть с разными моделями и юзерами. Если для статических меню, проблем не возникает, то проблемы возникают для пунктов меню, которые формируются динамически,"на лету", зависимости от того, кто посетил ресурс и с какого устройства посетил.
 

Для того, чтобы вставит тег необходимо в тексте слота указать:

Тег якоря HTML тег А, содержит аргумент (то, что отображается на экране) Аргумент, в зависимости от ситуации(язык, скин, тема) бывает необходимо заменить Для того чтобы заменить такой аргумент предназначена несколько иная форма:
 

подробно тут  http://www.cotonti.mobi/page.php?al=tag_processor

Чтобы не обрабатывать все чанки достаточно связать обработку с зоной $z - все просто.

Это конечно все хорошо, но причем тут чанки? 

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

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

Конечно не причем Dayver: вопросил, я ответил о решении со слотами  и.. и понеслось.

Я не против, если этот тренд удалят.

Добавлено 47 минуты спустя:

О чанках. Еще раз перечитал. Мой взгляд:.

В любом модуле есть такое или похожее подлючение темплейта:

$mskin = sed_skinfile(array('page', $sed_cat[$pag['page_cat']]['tpl']));
$t = new XTemplate($mskin);


//что там считаем и решаем и назначаем теги
$t->assign(array(
	"ТЕГ!" => $решение_тега1,
	"ТЕГ2" => $решение_тега2,

	"ТЕГN" => $решение_тегаN
));

//........
$t->parse('MAIN');
$t->out('MAIN');

Но можно и так

$mskin = sed_skinfile(array('page', $sed_cat[$pag['page_cat']]['tpl']));
$t = new XTemplate($mskin);

$mskin_чанк_1 = sed_skinfile('темплейт чанка_1');
$t_чанк_1 = new XTemplate($mskin_чанк_1);
$t_чанк_1->parse('MAIN_ЧАНКА');
//
$mskin_чанк_N = sed_skinfile('темплейт чанка_N');
$t_чанк_N = new XTemplate($mskin_чанк_N);
$t_чанк_N->parse('MAIN_ЧАНКА');





//что там считаем и решаем и назначаем теги
$t->assign(array(
	"ТЕГ!" => $решение_тега1,
	"ТЕГ2" => $решение_тега2,

	"ТЕГN" => $решение_тегаN,

	"ТЕГ_ЧАНК_1" =>$t_чанк_1->text("MAIN_ЧАНКА"),

	"ТЕГ_ЧАНК_N" =>$t_чанк_N->text("MAIN_ЧАНКА")
));

//........
$t->parse('MAIN');
$t->out('MAIN');

:

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

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

Ты объясни не детали реализации, а зачем это надо

Из http://www.cotonti.mobi/page.php?al=shopfront_project_matrix_and_copy для этого

Списки

Чтобы понять, что такое связанный список, достаточно записать нужное из товаров ТЦ для девушки,чтобы она стала эффектной. Покупательница, строго и требовательно, оценивает свой гардероб, она ищет в магазинах то, что подходит ей. То есть, если мы заведем элемент, который указывает на девушку, как покупательницу, то с ней можно связать некоторое множество — список вещей из ее гардероба. Общий признак этого списка «гардероб». А теперь возьмем и объединим в список множество гардеробов других девушек. Тогда, мы получим список размещения, множество вещей всех гардеробов.

А что понимает под списком размещения продавец? Допустим, имеется список всех помад, которые продают все продавцы ТЦ. Это список «Помады», список всех помад ТЦ. Это список размещения. Однако, нам известно, что для каждого цвета помады подходит свой список подходящих аксессуаров: шейный платок, платье, туфли... феррари подходящего цвета. Мы имеем явно связанный список с конкретной помадой. Возникает вопрос, а как организовать такой список? Да очень просто, каждый продавец, «Инициатор», может предложить свой товар, подходящий к помаде аксессуар. Назовем такой список «Аксессуары» Владелец товара «Помада» выступает как «Реципиент»: элемент дающий согласие на принадлежности элемента, например шарфика к конкретному списку «Аксессуары» помады, связанного списка товаров с конкретной помадой.

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

Сковорода квадратная

По мне это все как «Сковорода квадратная». Ты объясни не детали реализации, а зачем это надо. Я юз кейс не понимаю. Чтобы контент менеджер мог указать какой шаблон использовать и какой текст для новости выводить?

#39770 Sergey:

введения псевдонимов для страниц.

А что дают всевдонимы?

Теперь об адаптивности. Это направление предлагалось в самое начало создание Котонти...

Адаптивность больше относится к визуализации, и как результат к шаблонам. В чем трудность сделать адаптивную тему? 

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

Ок. Котонти всегда открыт новым и масштабным идеям. Но где они?… 

А что дают всевдонимы?

Начну с плагина новости. В пределах статьи есть скрытая страница с псевдонимом news

обявлена так:

[-новая страница=news]

знак минус это как раз теневая страница. Теневые страницы воспроизводятся по требованию. 

У меня может быть так: новость, что есть новый товар по цене, новость что такой товар со скидкой и подобное. У меня, одна статья может располагаться в нескольких разделах (категориях), а в установках плагина можно указать, из каких категорий нужно выводить новости. Плагин рассматривает очередную категорию. Прежде всего он готовит общее обрамление для категории. Находит темлейт типа news.очередная_категория.tpl. В этот шаблон парсятся все новости этой категории. Это сделано так, чтобы можно выводить новость категории похожим образом. Например словом: Сковорода квадратная, скидка 70%, а в другой категории можно вывести новость:Сковорода квадратная, цена 3 рубля.

когда оформляется статья с описанием квадратной сковороды, то заполняется страница news. В ней мы указываем альтернативы. Выбирается только одна альтернатива. Альтернатива это именнованный абзац с ключами активации.для примера это будет так:

[title,news=скидка]Обалденная сковорода с оболденной скидкой [/title]

Сковорода квадратная, скидка 70%

[title,news=цена]Что -то нужное за три рубля [/title]

Сковорода квадратная, цена 3 рубля

--

Плагин находит страницу новостей (пседоним news) А в ней нужную альтернативу. Для каждой группы новостей выводится свой вариант новостей. А вот и адаптиность RESS, есть метки устройства отображения, типа брааузера, кто зашел и т.д. 17 стандартных ключей. Естественно альтернатив может быть тьма. Но на само деле, обычно несколько. RESS это адаптивность на стороне сервера, зачем тащить все на сторону клиента и упражнятся с джавой для выборки нужного? Нужно отбирать нужное в нужном формате отображения на стороне сервера, а не на стороне клиента, потому bootstap это путь для статичных сайтов, но не для описываемого, динамичного..

Итак имеем два шаблона: один общий как новость, другой как новость категории. А теперь по теме новости. Тот шаблон, который по категории новости парсится в конечном виде так:

$mobinews->parse("NEWS");
	$t->assign('MOBINEWS'.$суффикс, $mobinews->text("NEWS"));

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

А что дают всевдонимы?  можем иметь страницу с псевдонимом доставка, чек, счет и т.д. на что способны. Важно только то, что данные идентифицируются и выбирается удобная альтернатива или для обработки или для отображения.

http://www.cotonti.mobi/page.php?al=mobile_web_news

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

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

Про адаптивность конечно тут вообще не в тему, но замечу. Адаптивность это немного не та фишка, которая нужна всегда и везде и как было отмечено выше это все-таки больше вопрос верстки и не считаю этот момент создает какие-то проблемы для существования и развития Cotonti. 

введения псевдонимов для страниц.

А что дают всевдонимы?

Теперь об адаптивности. Это направление предлагалось в самое начало создание Котонти...

Адаптивность больше относится к визуализации, и как результат к шаблонам. В чем трудность сделать адаптивную тему? 

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

Ок. Котонти всегда открыт новым и масштабным идеям. Но где они?… 

Выделенная строка ввела в ступор т.к. думал, что речь о том, что скрипты грузятся только там где используется тег слота. А оказывается ресь о теге HEADER_MYADSCONNECTS.

 {HEADER_MYADSCONNECTS} и {FOOTER_MYADSCONNECTS} - два универсальных тега, помимо слотов для меню. 

{HEADER_MYADSCONNECTS} - устанавливается в header.tpl , и все внешние скрипты которые добавляются в его поле в админке, выводятся эти тегом.

{FOOTER_MYADSCONNECTS} - устанавливается в footer.tpl , и все внешние скрипты которые добавляются в его поле в админке, выводятся эти тегом в футере.

Это теги именно для внешних скриптов. 

Например adsense , дает код, 1 - внешний скрипт, который размещается в header или footer .

Остальная часть - в нужном месте вывода рекламного блока. 

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

Это не касается тегов самих слотов в плагине, которые имеют формат {PHP.myads1} , они глобальные 

Я когда читаю твои посты ужасаюсь, т.к. половину текста не могу осмыслить. Представляю, сразу что мои посты, наверное, тоже не все догоняют.

Да это так.

Котонти не смог идеологически выйти  из идей LDU.  Оливье потому ушел из своего проекта, потому что не увидел его развития, а если и увидел, то понял что не потянет. Даже больше, тот вариант потерял, например, приоритеты администраторов и модераторов. В Седетио появились страницы, но развития этой идеи не произошло. Хотя, надо признать, что я выкладывал модуль с решением введения псевдонимов для страниц. Теперь об адаптивности. Это направление предлагалось в самое начало создание Котонти... но другие в это время делали твиттер и фейсбук, а могли бы быть ими мы. В настоящее время я не вижу развитие самой концепции Котонти. Да, есть решения, улучшения, плагины, - это все интересно для текущего выполнения гребка веслом, но никуда не плывем.

Плагин такой я уже сделал, Плагин называется Myads  

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

Добавлено 21 минута спустя:

Для таких целей в плагине Myads предусмотрено два поля, в которые можно добавлять любое количество внешних скриптов, каждый с новой строки. Это удобно тем, что вы один раз в шаблоне header.tpl и footer.tpl добавляете специальный тег, который также как и блоки можно в любой момент включить или выключить. Все скрипты которые будут прописаны в соответствующее поле, появятся автоматически в том месте, где выведен тег.

Выделенная строка ввела в ступор т.к. думал, что речь о том, что скрипты грузятся только там где используется тег слота. А оказывается ресь о теге HEADER_MYADSCONNECTS.

Добавлено 12 минуты спустя:

#39766 Sergey:

Я когда читаю твои посты ужасаюсь, т.к. половину текста не могу осмыслить. Представляю, сразу что мои посты, наверное, тоже не все догоняют.

#39766 Sergey:

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

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

#39766 Sergey:

Я так прикинул, то очень даже интересная мысль, которая вообще нигде не встречалась. Действительно, слот можно разрезать, разрезать дальше и собрать в нечто единое.

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

Да, аналогия во многом прослеживается. Но в Сиене очень многое делается в разы проще. 

На http://www.cmsmagazine.ru была дискуссия по поводу адаптации ресурса, ко всему. Хотел было и я поучаствовать, но когда стал готовить материалы, то начал выяснять истоки слотов. Впервые это стало применяться в игровых автоматах и в дальнейшем получило развитие на игровых сайтах. И все. Больше никакого развития. Естественно, я свое причесал и начал соображать куда и как применить. Однако, передумал выкладывать, так как акулы 1С (они организовали эту дикуссию) меня бы просто ... Сама концепция слотов развивается в рекурсивности. Я так прикинул, то очень даже интересная мысль, которая вообще нигде не встречалась. Действительно, слот можно разрезать, разрезать дальше и собрать в нечто единое. Это как разрезать большое фото на части и резать дальше, заменяя фрагменты, а потом все склеить. Это новый дизайн. Нечто похожее на плитки. Но слоты не получили развитие. На пути такой реализации я встретил проблемы логического характера типа колец времени. Пока я это пробую.

Изначально, я просто взял статью, страницы которой имеют тождественные псевдонимы (алиасы). В сиене нет такого. Ну так страница с алиасом menu1 это слот menu, страница с алиасом menu2 это слот menu2,  и так как гравится. Конечно можно и не так строго, как было построение слотов ранее, можно просто придумать свои имена... но я так не стал делать, есть некоторые логические проблемы. Ограничился изначально определенным пространтвом имен слотов.

"в Сиене очень многое делается в разы проще" - да никак не делается, нечего обсуждать в этом разрезе. Конечно, такое развитие требует значительной переработки самого движка. В моем решении введено понятие модели отображения, альтернативы содержания... и пр. непревычное. Конечно, казалось бы, можно ввести отдельные с логикой темплейты для слотов, можно, но что это даст?  Такое решение на поверхности, это парсить в тег представляющий слот, что было изначально с LDU. Но, такое решение всегда требует программиста.

 Потому будь у меня время я перенс бы слоты из ядра в плагин, 

Плагин слотов уже есть, называется Myads

Для таких целей в плагине Myads предусмотрено два поля, в которые можно добавлять любое количество внешних скриптов, каждый с новой строки. Это удобно тем, что вы один раз в шаблоне header.tpl и footer.tpl добавляете специальный тег, который также как и блоки можно в любой момент включить или выключить. Все скрипты которые будут прописаны в соответствующее поле, появятся автоматически в том месте, где выведен тег.
 

#39758 Dayver:

 Потому будь у меня время я перенс бы слоты из ядра в плагин, сделал бы возможность управлять их количеством, снабдил бы возможностью их подписывать (что б можно было написать что сей слот\чанк используется там то и там то) и работать в них логике

http://www.cotonti.mobi/page.php?al=Mobile_web_Slots

Да, аналогия во многом прослеживается. Но в Сиене очень многое делается в разы проще. 

 Потому будь у меня время я перенс бы слоты из ядра в плагин, сделал бы возможность управлять их количеством, снабдил бы возможностью их подписывать (что б можно было написать что сей слот\чанк используется там то и там то) и работать в них логике

http://www.cotonti.mobi/page.php?al=Mobile_web_Slots

 Зачем он? - не понял

В целом твои рассуждения в посте не далеко от сути всего этого замеса. :) 

Мы тут вчера в Skype часа 4 подробно по косточкам разбирали что это, кому из это что надо, и как это можно сделать. 

Кинул тебе подробности на мыло.

Скажу только о своем опыте и том о чем говорил Macik - я периодически в проектах плотненько использую слоты, какие они не корявые как бы мало их небыло но всеравно это удобнее чем стопятцот файлов кусков кода\ленгов и т.п. (да еще и если на странице рядышком с тем что выводит слот стоит ссылка на его редактирование и отображаемая только избранным) Почему? - да потому что их можно через админку править, а раз нельзя сделать в админке редактор чего нибудь в файлах (ресурсов, ленгов, шаблонов) из-за проблем с безопасностью то без функционала слотов никуда. Кто поспорит что менять нечто через админку это удобно? Тут писали что как бы не старались заказчики выбрать на начальном этапе программиста и\или цмску но всеравно они полюбому привяжут себя либо к одному либо к другому, а раз так то и хрен с ним что заказчику при необходимости придется либо самому лезть в файлы либо пинать\искать программиста - но это в корне не верно. Пример из жизни: дают веб-мастеру копейки что бы сделать простейший сайт точнее тупо засетапить двиг и сделать тему к нему на основе готовой верстки - все сайт визитка готов все рады. Проходит пол года заказчик по пьяни теряет номер телефона который висит на сайте в шапке и подвале. Блин через админку ниче не сделаешь потому что вообщето вебмастер мудак, где он не известно, потому что неизвестно что телефон в шаблоне, потому что ваще хрен знает как сайт работает, что такое цмс, кто такой котонти и ваще руки из жо что бы лезть куда то редактрировать файлы с фтп да и что это такое. Все ищут программиста. А терь скажите как должен был бы поступить веб-мастер уже с нашим котом в самом начале (даже если б заплатили хорошо и сделать надо было тоже хорошо) куда он бы распихал верстку? Ну да по правильному бы стили в css, разметку в шаблон(ы), тексты в ленг файлы, контент в базу. Но это б ничего не изменило ибо ни ленг, ни ресурс, ни шаблон из админки не исправить. Да пусть заказчик зовет специалиста если нужно изменить стиль\разметку, ну ладно в нашем случае и если надо язык системы, но некоторые вещи должны иметь возможность менятся так же как и контент из админки. Потому будь у меня время я перенс бы слоты из ядра в плагин, сделал бы возможность управлять их количеством, снабдил бы возможностью их подписывать (что б можно было написать что сей слот\чанк используется там то и там то) и работать в них логике (по аналогие с тем как она работает в шаблонах). Практически все это, разрознено, но уже звучало.

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

Добавлено 2 минуты спустя:

#39702 esclkm:

мне например чаще не хатает множественных параметров для колбэк функций

согласен и мне