Что такое чанки в программировании
Примечание: ниже перевод статьи «On Streaming, Chunking, and Finding the End», в которой авторы рассматривают процесс передачи информации по HTTP-соединению и возможности для ускорения этого процесса. Мои комментарии далее курсивом.
Два способа передачи
Как и в большинстве механизмов передачи данных, в HTTP существует два основных способа отправить сообщение: «все и сразу» или «по частям». Другими словами, в HTTP есть возможность отправлять данные до тех пор, пока еще есть хотя бы что-то, что можно отправить, либо отправить все данные как одну логическую единицу, указав предварительно ее размер.
Если вы занимаетесь веб-разработками достаточно продолжительное время, скорее всего, вы уже знаете, как работает сброс буфера (flush) на стороне сервера. Этот метод позволяет начать отправку части данных пользователю, в то время как скрипт может продолжать выполнять некоторые, достаточно медленные, действия (скажем, ресурсоемкий запрос к базе данных). Если вы уже применяли эту возможность, тогда вы, вероятно, использовали преимущества потокового (streaming) механизма, хотя могли и не знать всех деталей работы HTTP-протокола.
Что нужно разработчикам?
Однако, это не такая уж и старая история. Если вы являетесь современным веб-разработчиком или администратором, который заботится о работоспособности кода, написанного веб-программистами, то вам придется, скорее всего, столкнулся лицом к лицу с HTTP-потоками в своей профессиональной деятельности. И потоки эти станут ее неотъемлемой частью — хотите вы это осознавать или нет — и все это в связи с постоянно увеличивающимся значением AJAX в современных веб-приложениях. Обоснованность решения об использовании AJAX для увеличения производительности и ответственность за его принятие разработчиками частично зависит от того факта, что HTTP (имея и некоторые другие интересные приемы) может отправлять и принимать данные в полностью поточном режиме.
Может быть, сейчас вы подумаете: «Круто, что протокол HTTP выполнит всю работу на меня, но мне, действительно, совершенно не нужно знать, как это конкретно там происходит. Почему я должен это знать? Я просто хочу это использовать эти проклятые потоки, но не быть в них гуру».
Дырявые абстракции
А сейчас мы можем повторить один из любимых «сполкиизмов» (Spolskyisms) — закон дырявых абстракций (Law of Leaky Abstractions) Spolsky — который утверждает следующее: Все абстракции протекают (All abstractions leak). Из этого закона существует важное следствие, которое мы можем сформулировать примерно следующим образом: Если у вас начнет протекать абстракция и вы не будете понимать, как она работает, то вы рискуете оказаться очень мокрым.
И это действительно так. Большую часть времени (как разработчиком, так и администратором) вам не придется беспокоиться о потоках. Все необходимые детали милостливо вынесены на отдельный уровень реализации HTTP-абстракции в ваших системных библиотеках, или в вашем клиентском браузере, или в вашем веб-сервере. Однако если бы реализация этого абстрактного уровня не была настолько хороша, что скрывала от нас всю внутреннюю кухню и не позволяла в большинстве случаев вообще о ней забыть, мы бы никогда не добились таких результатов. Вместо этого мы бы проводили все наше время в поиске материалов, например, этой статьи.
Но предположим, что сейчас вы администрируете веб-приложение с AJAX и вы что-то изменили в конфигурации сервера, а один-единственный виджет внезапно стал «подвисать». При этом все будет в абсолютном порядке как со стороны браузера, так и со стороны сервера, и данные так же передаются по сети в соответствии с настройками. Или, например, вы реализовываете веб-сервис, и он замечательно работает до тех пор, пока заказчик не просит своего провайдера использовать протокол HTTP 1.1 для передачи данных вместо HTTP 1.0 . В этот момент все ломается, и сообщения более правильно не парсятся. Случаи, подобные описанным, а также ряд других «сверхъестественных» явлений могут быть результатом того, что абстракция HTTP-потоков дала сбой.
В конце концов, это может оказаться весьма полезным — знать некоторые основополагающие концепции и наиболее важные выводы из них!
А что, если.
Например, до прочтения этой статьи вы знали уже, что в HTTP существует два разных способа для передачи потока данных? На самом же деле, всего можно насчитать целых три способа отправки HTTP-сообщения от провайдера к клиенту. А вы знаете, что каждый из этих способов построен на различной реализации более низкого уровня протокола, например, TCP? В частности, вы сможете ответить, как изменения на уровне отправки HTTP-сообщений отражаются на длительности более низкоуровневого TCP-соединения?
Уже запутались? Если так, не переживайте. Это наша миссия — объяснять вещи такого рода тем веб-профессионалам, которые ищут знаний. Хотя мы всегда немного удивляемся, насколько мало тех — даже весьма бывалых и подготовленных, — кто до конца понимает, о чем идет речь. К счастью, HTTP-потоки, на самом деле, не настолько сложная вещь для понимания. Все, что нужно, — это просто начать с конца.
Начнем с конца
Нет, это не опечатка. Мы, действительно, начнем с конца. Примерно так:
HTTP-сообщения могут нести в себе полезные данные (как бы это не парадоксально звучало 🙂): тело сообщения в HTTP-потоке (но не всегда, потому что есть еще и HEAD-запросы). Если это происходит, то HTTP-реализация, которая работает с этими данными, должна знать, когда данные эти заканчиваются. Это обязательное условие и для пользовательского клиента, например, браузера, и для поискового робота, и для поставщика веб-сервисов, и для сервера, который принимает данные от клиента, например, в случае POST-запросов. Ключевым моментом в понимании HTTP-потоков будет подробный анализ процесса, в результате которого становится известным конец HTTP-сообщения, чтобы в дальнейшем обработать полученные в сообщении данные.
Три способа закончить
Существует только три возможных способа для процесса узнать, когда закончилось сообщение, которое он принимает. Как вы могли предположить, эти три способа делятся на один непотоковый вариант отправки данных в HTTP и два потоковых:
Непотоковый случай. Наиболее топорным путем для уведомления принимающего процесса, что сообщение подошло к концу, будет использование HTTP-заголовка Content-Length . Если этот заголовок присутствует, HTTP-клиент или сервер могут подсчитать размер сообщения и сравнить его с заявленным в заголовке значением. Отправка статических файлов, практически, всегда сопровождается таким заголовком, и его значение соответствует размеру самого файла (в байтах). Сам же файл становится, таким образом, телом HTTP-сообщения (данные за минусом размера заголовка). Аналогичным образом, POST-запросы от клиента также содержат заголовок Content-Length .
Использование заголовка Content-Length позволяет просто и надежно узнать, где находится конец данных. К несчастью, это не позволяет посылать кусок за куском разного (случайного) размера. Сервер, посылающий данные потоком, не может в начале потока знать, сколько кусков осталось или какого размера каждый из них. Если бы он знал, ему вообще не нужно было бы слать данные потоком. Налицо дилемма.
Я так понимаю, что без заголовка Content-Length клиент никогда не узнает, смог ли он получить все сообщение от сервера или только его часть (например, из-за неожиданного разрыва соединения), что может существенно отразиться на целостности передаваемых данных.
Вводим потоки HTTP 1.0 . Если у HTTP-сообщения есть тело, но нет видимого конца содержания в самом его начале (в заголовке), тогда наиболее простым путем для сообщения HTTP-клиенту о том, что передача закончилась, будет закрытие нижележащего TCP-соединения. Нет ничего, что могло бы сказать: «Это все, ничего больше не будет» — лучше, чем закрытое соединение. Если вы используете любой анализатор протокола HTTP (например, HttpWatch или Live HTTP Headers) для отслеживания заголовков в HTTP-ответе, который передается по этому методу, то вы, скорее всего, увидите следующий заголовок:
указывающий на то, что сервер собирается закрыть нижележащее соединение, как только закончит передавать данные (технически, этот заголовок может и не присутствовать в контексте HTTP 1.0 , так как для HTTP 1.0 , по умолчанию, используется одноразовое (non-persistent) соединение, которое подразумевает, что в 1.0 реализации оно будет закрыто, если только сообщение не сопровождено заголовком Connection: Keep-Alive ). Если вы взгляните, что происходит с ответом на уровне TCP/IP (например, при помощи Wireshark или равноценного инструмента), вы увидите, что сразу после того, как сервер отправляет остатки данных в сообщении, для которого указан заголовок Connection: close (или не указано никакого заголовка Connection ), сервер, фактически, инициирует двустороннее закрытие на уровне TCP, отправляя пакет с выставленными битами FIN и ACK . Это все замечательно отрабатывает и сообщает клиенту, что поток подошел к концу.
Хотя, очевидно, что в таком случае присутствует следующий неприятный момент, связанный с дополнительными издержками. Да, сервер сообщил клиенту, что данные закончились. Но ценой этого стал разрыв TCP-соединения, с помощью которого пересылались данные. И его придется восстанавливать через «тройное рукопожатие», если нужно передать еще одно или несколько сообщений. Это извращает саму идею того, что в HTTP 1.0 называется элементами поддержки установленного соединения (keep-alive) (или что мы называем в HTTP 1.1 постоянным соединением (persistent connections)).
Это так плохо? Ну, в общем, да, это может быть достаточно неприятно в зависимости от обстоятельств. Повторное использование существующих TCP-соединений, если есть такая возможность, позволяет существенно повысить производительность сервера. В результате таких соединений не только экономится время на установление новой пары TCP/IP-сокетов, они также позволяют использовать сетевые ресурсы более оптимальным образом. Это справедливо как для браузеров, которые могут отправлять множественные запросы через небольшое число установленных соединений при загрузке страницы, на которой присутствует много ссылок на внешние ресурсы. Это справедливо и для серверов, которые могут быстро собирать существующие соединения по истечению TIME_WAIT состояния, если клиенты оказываются не в состоянии их поддерживать. Являясь опциональными в HTTP 1.0 (где они устанавливаются с помощью заголовка Connection: Keep-Alive ), в HTTP 1.1 постоянными соединения, по умолчанию, были включены — специально, чтобы предотвратить проблемы такого рода.
К несчастью, в HTTP 1.0 нет никакого другого способа, чтобы найти компромисс между передачей потока данных и сохранения соединения актуальным (alive). Вам придется выбрать что-то одно, потому что в данном случае клиенту никак нельзя сообщить о том, что данные закончились, кроме как оборвав сам поток.
Возможно, вы скажете, что хотели бы уйти от этого компромисса? Так и сделали те парни, что написали спецификацию HTTP 1.1 . Им очень понравился механизм Keep-Alive , который, по-видимому, был добавлен с сильным запозданием в HTTP 1.0 , и не позволял использовать потоки на полную мощность. Итак, в HTTP 1.1 было сделано два значительных изменения. Во-первых, постоянное соединение устанавливается по умолчанию (в противном случае вам нужно специально сообщить программе на другом конце потока, что вы собираетесь это соединение закрыть); во-вторых, к этому было добавлено что-то, названное «кодированием передачи с помощью чанков» (chunked transfer encoding).
Это выражается в появлении в заголовках HTTP 1.1 ответа следующего:
что означает, что сообщение передается при помощи этой кодировки. Если взглянуть на диаграмму ответа на TCP/IP уровне, то можно заметить, что соединение остается открытым даже после передачи всех данных, связанных с этим заголовком: сервер не отправляет FIN/ACK после последнего чанка данных. Вместо этого уже открытый сокет обычно используется для следующего по очереди запроса.
Рисунок 1. Схема TCP/IP-соединения
Как это возможно? Или по-другому: откуда браузер узнает, что он получил конец данных в потоке? В конце концов, он уже не может это знать наверняка из того факта, что соединение было закрыто.
Если используются чанки, то это обеспечивает браузер информацией о том, в каком месте потока он находится в данный момент и когда этот поток заканчивается. Во-первых, перед каждым чанком данных передается поле, которое указывает его длину в байтах, используя шестнадцатеричное представление (через ASCII-символы). Каждый блок, состоящий из поля с длиной и соответствующего чанка данных, заканчивается символом CRLF (Carriage Return Line Feed, возврат каретки). Затем следует следующий блок с длиной/данными и так далее, пока все данные не будут получены. Поле с длиной отсутствует только у последнего чанка, потому что оно всегда равно нулю. Если говорить более точно, оно всегда содержит значение 0 перед закрывающим CRLF . таким образом клиент всегда может определить, что поток с данными правильно закончился
Заключение
Надеюсь, этот краткий экскурс в потоки и чанки помогли понять эти основы HTTP-протокола, и он окажется полезным отладке веб-сайта и веб-приложений.
Какие выводы можно сделать из вышесказанного? Во-первых, для обслуживания веб-сайтов (для которых на одну страницу может приходиться несколько десятков запросов) стоит использовать протокол HTTP/1.1 либо HTTP 1.0 совместно с Keep-Alive и Content-Length — это позволит избежать части издержек на установление TCP-соединения.
Если ваш сервер настроен на отдачу только одного файла одному клиенту (например, оно обслуживает только HTML-файлы, а статические ресурсы отдаются с другого сервера, или же это файловый сервер, с которого загружают большие бинарные файлы), то стоит использовать HTTP 1.0 и Connection: close (которое включено по умолчанию). Это позволит сэкономить ресурсы сервера на обслуживание соединений.
Чанки
Support the team building MODX with a monthly donation.
The budget raised through OpenCollective is transparent, including payouts, and any contributor can apply to be paid for their work on MODX.
$400 per month—let’s make that $500!
Чанки — это кусочки статического текста, которые вы можете повторно использовать на своем сайте. По функциям они похожи на файлы или «блоки» в других системах управления контентом. Типичными примерами чанков могут быть ваша контактная информация или уведомление об авторских правах. Хотя чанки не могут содержать никакой логики напрямую, они могут содержать вызовы Сниппетов, которые являются исполняемыми битами кода PHP, которые производят динамический вывод.
Создание¶
Прежде чем вы сможете использовать чанк, вы должны сначала создать и назвать его, вставив текст в менеджер MODX (Элементы —> Чанки —> Новый чанк):
Использование¶
Чтобы использовать Чанк, вы ссылаетесь на него по имени в ваших шаблонах или в содержимом вашей страницы.
Эта ссылка затем заменяется содержимым Чанка.
Вы также можете передать свойства в чанк. Скажем, у вас был чанк с именем intro и содержимым:
Привет, [[+name]] . У тебя есть [[+messageCount]] сообщений.
Вы можете заполнить эти значения с:
Который будет выводить:
Привет, George. У тебя есть 12 сообщений.
Вы могли бы сделать еще один шаг, добавив Переменные шаблона что позволяет пользователю указать свое имя для каждого ресурса:
или в самом чанке:
Обработка чанка через API¶
Чанки также часто используются для форматирования вывода сниппетов. Чанк может быть обработан из сниппета с помощью функции process(); например, с учетом следующего чанка с именем rowTpl:
следующий сниппет кода извлекает его и обрабатывает его с массивом свойств для всех опубликованных ресурсов и возвращает отформатированные результаты в виде таблицы, устанавливая класс «alt» для четных строк:
Модификация чанка через API¶
Чанками также можно манипулировать с помощью MODX API:
Смотрите также¶
Support the team building MODX with a monthly donation.
The budget raised through OpenCollective is transparent, including payouts, and any contributor can apply to be paid for their work on MODX.
MODX — Чанки
Чанк — это элемент MODX, который представляет собой кусок текста или HTML-кода. Предназначен он для формирования некоторого фрагмента (куска, части) HTML-страницы. Например, чанк можно использовать для вывода раздела head HTML-документа, меню, блоков информации в основной и дополнительной области сайта, футера и многих других частей страницы.
Например, чанк (его содержимое), который используется для вывода меню сайта:
Кроме этого чанки в MODX Revolution также используются в качестве шаблонов для вывода результатов работы сниппета.
Например, чанк (tpl.Tickets.list.row), который используется в качестве шаблона сниппета getTickets :
Внутри чанках, как и во многих других элементах MODX Revolution (шаблонах, TV-параметрах, полях ресурса), нельзя непосредственно размещать php-код. Размещение в этих элементах динамического содержимого осуществляется посредством вызовов сниппетов, которые исполняют хранящийся внутри них PHP-код.
Совет: не храните повторяющийся код (раздел head , шапку сайта, меню, подвал, контактную информацию и др. блоки страницы) в шаблонах. Более предпочтительно всё это оформить в виде чанков, а затем использовать их в необходимых шаблонах. Это позволит сократить значительное количество времени, если потребуется внести изменения в некоторый блок. Вместо редактирования большого количества шаблонов, в данном случае потребуется всего внести изменения только в один чанк.
Где хранятся чанки
Чанки, как и остальные объекты MODX, хранятся в базе данных. Чанки содержатся в таблице modx_site_htmlsnippets (modx — это префикс таблиц, заданный во время установки системы).
Работа с чанками в админке MODX
Чанки в админке MODX Revolution расположены на левой панели во вкладке «Элементы».
Создание чанка
Создание чанка осуществляется с помощью кнопки «+». После нажатию на эту кнопку открывается страница, содержащая форму. Среди полей этой формы, основными являются имя и код чанка (html). Имя — это название, посредством которого этот чанк можно будет вызывать в шаблоне, содержимом ресурса или в другом месте. Код чанка (html) — это контент, который парсер будет выводить на месте вызова чанка.
Кроме этого система MODX позволяет хранить содержимое чанка во внешнем файле. Для этого необходимо установить галочку в поле статичный, выбрать источник файлов и указать его расположение.
Редактирование чанка
Для редактирования некоторого чанка в админке необходимо нажать на него левой кнопкой мыши. После этого откроется форма полями чанки, в которую необходимо внести изменения и нажать на кнопку «Сохранить».
Как использовать чанки в MODX
Вставка чанка в шаблон или содержимое ресурса осуществляется с помощью следующего тега MODX:
Во время обработки страницы, парсер MODX заменит тег чанка его содержимым.
Чанк и его параметры
Чанки в MODX могут иметь параметры. Например, рассмотрим чанк «intro», имеющий следующее содержимое:
Он имеет 2 плейсхолдера: [[+name]] и [[+messageCount]]. Передать значения этим плейсхолдерам можно с помощью указания соответствующих параметров вызову чанка:
В результате, получим следующее содержимое:
Если пойти немного дальше, то можно, например, создать TV-параметры name и messageCount , и добавить их (эти переменные) к соответствующему шаблону. После этого у каждого ресурса, имеющего этот шаблон, появятся эти TV-параметры. Значения этих TV-параметров можно использовать в качестве значений параметров чанка:
или в содержимом чанка:
Условия в чанках
Условия и другие фильтры MODX можно использовать в любых специальных тегах этой системы.
Например, внутри чанка в зависимости от идентификатора родителя текущего ресурса вывести один или другой чанк.
Но с фильтрами в MODX надо быть очень осторожными, т.к. они могут сильно увеличить время генерации страницы. Это происходит потому, что условия в тегах MODX работают не так как обычные условия в php. Например, в вышеприведённом примере оба чанка вызовутся, не зависимого от того какой идентификатор имеет родитель текущего ресурса. А уже только потом будет определяться какой из этих чанков будет выведен на страницу. Поэтому в MODX они и называются фильтрами. А теперь давайте представим, что в этих чанках есть вызовы некэшируемых сниппетов. В результате в не зависимости от идентификатора родителя текущего ресурса эти вызовы будут выполняться как в первом, так и во втором чанке. Это может привести к значительному увеличению времени генерации страницы и нагрузке на сервер. В таких случаях лучше фильтры не использовать, а выполнять эти действия с помощью сниппета.
Обработка чанка с помощью API
Чанки часто выступают в качестве шаблонов для вывода результатов работы сниппета. Обрабатывается чанк в сниппете через функцию getChunk().
Например, рассмотрим, как использовать чанк «rowTpl» в сниппете.
Чанк «rowTpl», имеет следующее содержимое:
Содержимое (php-код) сниппета, который получает все опубликованные ресурсы на сайте и выводит их в таблицу. Для вывода данных отдельного ресурса (одной строки таблицы, состоящей из 2 ячеек) используется шаблон rowTpl.
Как работать с чанками в ModX Revolution?
Добро пожаловать на 5 урок MODX Revolution для новичков. В предыдущем уроке мы начали рассматривать работу с шаблонами в MODX Revolution. Мы начали со статичного HTML/CSS шаблона и перенесли его в нашу установку MODX Revolution, изменили пути к файлам и начали изучать синтаксис тегов MODX Revolution и как его использовать. В этом уроке мы продолжим работу над нашим шаблоном и изучим концепцию чанков.
В данном уроке я использую шаблон 7-in-1 Business Success Site студии Themeforest. Если вы работаете над шаблоном, который вы скачали или сделали сами, то это даже лучше. Подход к построению сайта одинаков вне зависимости от используемого шаблона.
Давайте начнем. Наш сайт выглядит сейчас точно так же как и загруженный шаблон, потому что мы изменили все пути к css, js и image файлам. Давайте рассмотрим что же такое чанки
Чанки MODX Revolution
Чанки — это куски HTML кода или текста. Важно отметить что чанк — это чистый HTML код без всякой логики. Чанк не может содержать PHP код, он просто не будет выполнятся. PHP код необходимо вставлять в сниппет (разберёмся в этом в следующих уроках). Этот сниппет потом может быть вызван в чанке. В то же время чанк сам по себе не может содержать всередине чистый PHP.
Для чего использовать чанки?
Вы можете использовать чанки для различных целей. Некоторые примеры использования чанков включают организацию вашего шаблона в управляемые части, содержащие HTML или текст, который будет использован снова и снова в вашем сайте, а также для хранения мини-шаблонов для ваших меню и др. Сейчас это может быть не совсем ясно, но ситуация прояснится по ходу дела.
В этом уроке я собираюсь использовать чанки для организации моего шаблона в несколько управляемых частей. Как я уже упомянул в предыдущих уроках, эти занятия отражают лишь моё видение этого процесса, вы можете использовать свой лучший или более удобный вам способ.
Поэтому можете просто бегло ознакомится с данным уроком либо просто прочитать, чтобы понять синтаксис чанков и далее организуйте ваш шаблон как вам удобно.
Если мы посмотрим на код шаблона, над которым сейчас работаем, то увидим длинную страницу кода и в нём при редактировании или изменении части кода можно легко потеряться. Чтобы избежать этого, давайте разделим код на логические секции и далее сохраним эти секции раздельно как чанки, которые я потом смогу вызвать в главном шаблоне.
Видно, что этот шаблон разделён на три различные секции: шапка, подвал и средняя область (по такому принципу делятся почти все шаблоны). Соответственно можно поделить наш шаблон на эти три части. После разделения мы можем далее еще разделить эти секции.
Поэтому первой вещью, что мы сделаем — это создадим два новых чанка, которые назовём: 7in1-header и 7in1-footer.
Для создания чанка зайдем в менеджер и в дереве слева зайдем во вкладку Elements. Можно создать чанк двумя способами: правым кликом на Chunk и выбрать“New Chunk” или кликнуть на иконку Chunk.
В появившемся окне вводим необходимую информацию — имя чанка, описание и категория, если это необходимо.
Пока сохраним этот чанк, чуть позже вставим туда код.
Давайте продолжим и создадим чанк для подвала.
Сейчас если мы взглянем на дерево ресурсов, то увидим наши два новые чанка в разделе Чанки.
Итак, наши чанки готовы к использованию. Всё, что нужно сделать, это вырезать код из секции нашего шаблона и вставить в чанки. В моём случае, я открою шаблон 7in1 Home, который мы создали в предыдущем уроке и вырежу весь код между отрывающим и закрывающим тегами <head>. Далее я вставлю этот код в средину чанка 7in1-header, который я только что создал и сохраню его.
Если мы теперь посмотрим на наш сайт, то увидим, что он не выглядит так, как должен выглядет.
Это случилось потому что сайт больше не видит наших css и js файлов, так как мы вырезали всю информацию об этом из нашего шаблона. Так как эта информация теперь содержится в чанке, то нам необходимо просто вызвать чанк в шапке шаблона.
Как вызывать чанк в MODX Revolution
Синтаксис чанков в MODX Revolution очень прост:
В нашем случае мы просто перейдём в наш шаблон и разместим там вызов нашего чанка 7in1-header в области, где мы убрали код шапки. Таким образом верхняя часть кода нашего шаблона будет иметь следующий вид:
Если сейчас вы перезагрузите страницу, то увидите, что она примет нормальный вид. Это значит, что парсер MODx видит вызов чанка, он берёт его содержимое и размещает в области, где сделан вызов. Если вы знакомы с программированием PHP, то вы увидите схожесть с концепцией использования включения файлов.
Отлично, теперь мы знаем что делать дальше и сделаем ту же процедуру с подвалом. В моём случае я выделю весь код от начала div подвала до закрывающего тега и размещу его в чанке 7in1-footer, который мы создали. Затем размещу вызов это чанка в нужном месте. Теперь конец кода моего шаблона выглядит вот так:
Снова напомню, можете делать что угодно и как угодно, можете вообще не делить ваш шаблон :). цель данной демонстрации — это показать как работать с чанками и какой их синтаксис при вызове чанков в шаблоне.
Для моих целей, я собираюсь еще поделить мой шаблон и добавить пару чанков. Эта секция шаблона появляется в основном на каждой странице вебсайта:
Я думаю разумно разместить код для этой секции в собственном чанке и далее вызывать его в наших шаблонах. Я назову этот чанк 7in1-bottomwidgets и таким образом нижняя часть кода моего шаблона приобретёт следующий вид:
Как вы видите, в зависимости от внешнего вида нашего шаблона, мы можем делить его дальше и дальше в отдельные чанки либо же не делить совсем.