Forums / National / Russian / Идеи / Chunks

«О CoTemplate»

Кроме прочего, если уж опять «расширять» CoTemplate, то я бы приделал универсальный механизм, позволяющий расширить шаблоны произвольным синтаксисом, за счет вызова сторонних функций. Т.е. сторонний плагин регистрирует в классе маркеры (метки) которые он хочет парсить и назначает на их обработку свои функции, а шаблонизатор при обработке шаблона проверяет список зарегистрированных, и при необходимости вызывает указанные функции отдавая содержимое тега. Тогда расширение шаблонизатора, в случае необходимости будет как раз-два.

Только хотел написать, что не хватает выхова сторонних функций в парсере, это упростило бы задачу. Полностью согласен. 

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

А вот с хранением в базе данных всех чанков, мне кажется не совсем приемлемым. Какой объем данных тогда будет выгружать БД при загрузке? Используя CoTemplate все кешируется и выводится как обычно.. вот только о передаче параметров я не думал еще надо ли?  Я не имел ввиду копию модикса, а некое более удобное использование кусков шаблона ..

Приветствую всех присутствующих, вижу актуальная тема поднялась.  

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

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

Я много работал с шаблонами ДЛЕ , где все делается хаками, так как модули ставятся только с правками движка в большинстве случаев.

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

Но по сравнению с ДЛЕ , Cotonti в разы лучше, и более гибкая в реализации задумок. Просто нужно смотреть не глазами программиста, а глазами нуба, тогда станет все понятно, чего здесь не хватает. 

Я начал писать плагины которые нужны в первую очередь при взгляде со стороны пользователя. Например работа с внешними ссылками, кнопка скроллинга вверх, галерея изображений, визуальный редактор с поддержкой bb и html парсинга, поделиться, подсветка кода, подключение сторонних скриптов и баннеров в админке (типа слотов для меню).

Сейчас работаю над новой интуитивной каптчей, сделал проверку и валидацию при регистрации на ajax, чтобы не было логинов типа 01 или 1as , или AsAAA.

Может стоит использовать старый метод сеошников, под названием анализ конкурентов?

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

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

Например в том же ДЛЕ меню отсутствует, все работы идут в шаблоне, а улучшения - в правках ядра, и при этом запрос по вордстату - больше 70000.

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

Насчет включений - если структура шаблона будет четко разбита на части, то работать с ним в разы легче.

Конструкция FILE это шикарное решение само по себе, я давно храню все интегрируемые объекты в папке inc шаблона. Меню, поиск, сайдбары, каждый отдельно, и все в индексных шаблонах включаются только конструкцией. Поэтому например header.tpl используется как каркас, а в нем:

<!-- меню -->

{FILE "themes/{PHP.theme}/inc/menu.tpl"}

<!-- кабинет -->

{FILE "themes/{PHP.theme}/inc/beginuser.tpl"}

и тд

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

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

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

3. Если в админке без ущерба для безопасности можно реализовать открытие и правку tpl и css файлов, это плюс. В том же ДЛЕ это реализовано.

Получается что идет замена конструкции FILE при вызове .tpl файлов из папки?    

а как будет идти вызов файла в index, page, forums?    с header и footer понятно, они есть глобально, а как быть с содержимым блоков типа MAIN ?

например у меня во всех нужных файлах типа main сайдбары вызываются {FILE "themes/{PHP.theme}/inc/s_left.tpl"} и {FILE "themes/{PHP.theme}/inc/s_right.tpl"}

#39722 PRoHtml:

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

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

Это в зависимости от функциональности чанков. В идеале отдельный плагин. Но судя по запросам придется каким-либо образом расширять CoTemplate. 

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

Не понял мысль. Если не будет доступна функциональность чанков, то они (в зависимости от реализации) либо остануться в тексте страницы не обработанными, либо будут «удалены» при парсинге.

3. Если в админке без ущерба для безопасности можно реализовать открытие и правку tpl и css файлов, это плюс. В том же ДЛЕ это реализовано.

Я бы постарался этого избежать.

#39721 Dr2005alex:

Соглашусь с PRoHtml , котонти уже вполне пригоден для программистов. Я к этому и клоню - будем ли мы делать его более понятным для новичка?

Вернусь к основной теме чанков. Вопрос кто за введение чанков?

1. Должны ли чанки быть редактируемые из админки?

Считаю, что да, при условии, что мы не редактируем файлы на диске (см. ниже).

1. Хранение чанков в файле, в б.д., микс

На сколько мне видится применение чанков (небольшие блоки кода, редактируемые менеджером сайта) — они удобнее в БД, но как писал выше можно сделать настраиваемо.

1. Нужны ли входные параметры чанков? (Хотя мне кажется нет т.к. в них как обычно работают теги, условия шаблоны и т.д.) 

Я склонен к варианту с опциональными параметрами, т.к. это увеличит гибкость и модульность элементов интерфейса. Например выделить html код кнопки или виджета в чанк и вызывать его «наполняя» определенным контентом (передавая через параметры).
Но начать можно и с простого варианта без параметров.

В моем понимании чанки для котонти это именно куски html кода со стандартным набором тегов, которые соединяются воедино в базовом шаблоне. Это будет большим плюсом для скинмэйкеров. Можно создать пару-тройку базовых скилетов для сайта (типа 2 столбца, 4 ,  с footer и без) и прописать в них места блоков, куда и будут вставлятся чанки. Скинмэйкер сможет наделать кучу вариантов шаблонов. Меняя только базовый скилет шаблона и подкулючая готовые чанки.

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

так вот я предлогаю ввести аналог 

<!-- меню -->

{FILE "themes/{PHP.theme}/inc/menu.tpl"}

<!-- кабинет -->

{FILE "themes/{PHP.theme}/inc/beginuser.tpl"}

но с более жесткими условиями. т.е. будем использовать к примеру такой вид.

<!-- меню -->

{CHUNK.MENU}

<!-- кабинет -->

{CHUNK.BEGINUSER}

И кроме как tpl файл чанк не подгружает..

#39727 Macik:

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

Не понял мысль. Если не будет доступна функциональность чанков, то они (в зависимости от реализации) либо остануться в тексте страницы не обработанными, либо будут «удалены» при парсинге.

Подразумевалось, если чанка выводит определенный .tpl файл, и в него нужно , например добавить экстраполе, или функцию вывести, а она не работает.

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

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

#39730 Dr2005alex:

Да походу только через правку шаблонизатора можно одолеть. Я поспешил с глобальными тегами)))) Через плагин можно сделать только такую конструкцию для подключения чанка {PHP.chunk.name} или вызовом функции {PHP|cot_chunk('name')}, но тогда теряется смысл легко подключения чанков. Либо перечислять все теги плагине, где плагин должен подключать чанки. Все хуки tags. что бы иметь конструкцию к примеру {[CHUNKNAME]} 

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

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

#39730 Dr2005alex:

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

Да. Только сделать это надо красиво и продуманно, с перспективой на будущее. (см. ниже)

Через плагин можно сделать только такую конструкцию для подключения чанка {PHP.chunk.name} или вызовом функции {PHP|cot_chunk('name')}, но тогда теряется смысл легко подключения чанков.

Главное, что в таком случае мы теряем возможность использовать внутри чанков теги текущего шаблона (в котором чанк используется), и все «скатывается» к прямому аналогу слотов с парсингом а-ля «slot-n-tags». 

Либо перечислять все теги плагине, где плагин должен подключать чанки. Все хуки tags. что бы иметь конструкцию к примеру {[CHUNKNAME]} 

Нет, это совсем не вариант.

---

На счет универсального расширения CoTemplate мысль такая:

• выбираем единый синтаксис открывающих и закрывающих скобок для «расширенных» тегов, например {{ }}, или как в новом МодИксе [[ ]] ( сейчас не важно)
• внутри скобок первым делом идет управляющий оператор, пример — {{CHUNK: }} 
• на основании имени оператора вызывается соотв. функция прописанная в самом CoTemplate или сторонняя, зарегистрированная предварительно через механизм самого CoTemplate. Т.е. если мы нашли конструкцию {{YYY: тело_расширенного_тега}} вызывается функция «привязанная» заранее к оператору `YYY` и ей передается полное «тело_расширенного_тега» и контекст вызова, т.е. ссылка на экземпляр XTemplate в котором идет работа.
• Далее уже от заданной функции зависит как `тело_расширенного_тега` будет парсится, чем будет заменяться, будут ли у него параметры и т.п.

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

// условный код на PHP

// в хуке global регистрируем свои обработчики
XTemplate::set_extender(array(
  'CHUNK:' => 'cot_chunk_parse',
  '$' => 'cot_chunk_parse', // тоже самое но в стиле ModX
));

// в плагине, описываем функцио обработки, которая будет заниматься всем дальнейшим процессом обработки
/**
* обработка чанков
*
* @param array $found_ext_tag массив содержащий PCRE совпадения, содержит:
*     $found_ext_tag[1] — имя расширенного тега, например `CHUNK:`
*     $found_ext_tag[2] — тело расширенного тега для дальнейшей работы
* @param XTemplate $tpl_context ссылка на текущий экземпляр CoTemplate (из которого осуществлен вызов)
* @return string
*/
function cot_chunk_parse($found_ext_tag, $tpl_context){
  /* парсим $found_ext_tag[2] для получения имени конкретного чанка, его параметров и т.п. в зависимости от установленного синтаксиса */

  // …

  return $parsed;
}

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

#39733 Dr2005alex:

Вот файл cotemlate.php с коррекцией.

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

Предлагаю более универсальный вариант — см. выше.

#39736 Dr2005alex:

не совсем поятен это кусок 

// в хуке global регистрируем свои обработчики
XTemplate::set_extender(array(
  'CHUNK:' => 'cot_chunk_parse',
  '$' => 'cot_chunk_parse', // тоже самое но в стиле ModX
));

set_extender это что? 

В таком виде не будет работать.. ты наверное имел ввиду не в хуке global а в XTemplate?

set_extender это одна из функций, которой стоит расширить сам CoTemplate. Она будет регистрировать во внутреннем реестре соответствие имен расширенных тегов и их обработчиков.

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