Как обновить кэш твиг шаблонов

Обновлено: 04.07.2024

Русскоязычная документация по Twig - PHP шаблонизатору. Руководство по Твиг на русском языке

В этой главе описывается API для Twig, a не язык шаблонов. Это будет наиболее полезным в качестве ссылки для тех, кто реализует интерфейс шаблонов для приложений , а не тем, кто создает шаблоны Twig.

Основы

Twig использует центральный объект, называемый environment (класс Twig_Environment). Экземпляры этого класса используются для хранения конфигурации и расширений и используются для загрузки шаблонов из файловой системы или других мест.

Большинство приложений создает один объект Twig_Environment при инициализации приложения и использует его для загрузки шаблонов. В некоторых случаях, однако, полезно иметь несколько сред совместно (рядом друг с другом), если используются различные конфигурации.

Самый простой способ конфигурировать Twig - это загрузить шаблоны для вашего приложения, что выглядит примерно так:

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

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

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

Для загрузки шаблона из этой среды вам просто нужно вызвать loadTemplate() метод, который возвращает затем экземпляр Twig_Template:

Чтобы передать переменные в шаблон, вызовите метод render():

Метод display() это наиболее простой метод вывести шаблон явно.

Вы можете также загрузить и воспроизвести шаблон одновременно:

Опции окружения.

При создании нового экземпляра Twig_Environment, вы можете передать массив опций как конструктор второго аргумента:

Доступны следующие опции:

debug: При установке в true, генерируемые шаблоны имеют__toString() метод, который можно использовать для отображения сгенерированных узлов (по умолчанию false).
charset: Кодировка, используемая в шаблонах (по умолчанию в UTF-8)
base_template_class: Шаблон базового класса ,который используют для сгенерированных шаблонов (по умолчанию Twig_Template).
cache: Абсолютный путь, где хранятся скомпилированные шаблоны или false чтобы отключить кэширование (который по умолчанию).
auto_reload: При разработке с Twig, полезно повторно компилировать шаблон при изменении кода-исходника. Если вы не установили значение опции auto_reload, то она будет определена автоматически на основании переменной debug.
strict_variables: Если установлено false, Twig будет по умолчанию игнорировать недействительные переменные (переменные и или атрибуты/методы, которые не существуют) и заменять их значением null. Когда устанавлено true, Twig генерирует исключение (по умолчанию false).
autoescape: Если установить true, авто-сохранение будет разрешено по умолчанию для всех шаблонов (по умолчанию true). Начиная с Twig 1.8, вы можете выбрать какую методику сохранения использовать (html, js, false для блокировки). Начиная с Twig 1.9, вы можете выбрать какую методику сохранения использовать (css, url, html_attr, или обратный вызов PHP, который берет шаблон "имя файла" и должен вернуть методику сохранения для использования -- обратный вызов не может быть названием функции, чтобы избежать конфликта (коллизии) со встроенными методами сохранения. optimizations: Флаг, который указывает, какие оптимизации применять (по умолчанию -1 -- все оптимизации разрешены; установите его на 0 для отключения).

Загрузчики

Загрузчики отвечают за загрузку шаблонов из такого ресурса, как файловая система.

Все загрузчики шаблонов могут кэшировать компилированные шаблоны в файловой системе для дальнейшего использования. Это значительно ускоряет Twig, поскольку шаблоны компилируются только один раз и увеличение производительности даже больше, если бы вы использовали ускоритель PHP, такой как APC. Смотрите cache и auto_reload опции Twig_Environment выше для получения подробной информации.

Вот список встроенных загрузчиков, которые дает Twig:

Новое в версии 1.10: prependPath() и поддержка пространства имен были добавлены в Twig 1.10.

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

Он может также искать шаблоны в массиве директорий:

При такой конфигурации Twig будет сначала искать шаблоны в $templateDir1 и если они не существуют, и он будет искать их в $templateDir2.

Вы можете добавить или вставить каналы (пути) с помощью методов addPath() и prependPath().

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

Используя методы setPaths(), addPath(), и prependPath(), определите пространство имен как второй аргумент ( если нет определения, то эти методы действуют на пространстве имени "main").

Шаблоны пространства имен могут быть доступны через специальное обозначение @namespace_name/template_path:

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

Этот загрузчик следует использовать только для unit-тестирования , поскольку он имеет строгие ограничения: несколько тегов, такие как extends или include не имеет смысла использовать, поскольку ссылка на шаблон сама является кодом источника шаблона.

Twig_Loader_Array загружает шаблон из PHP массива. Это передается ограничением массива строк до имен шаблонов.

Этот загрузчик очень полезен для unit-тестирования. Он также может быть использован для малых проектов, где хранение всех шаблонов может иметь смысл в одном PHP файле.

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

Twig_Loader_Chain перенаправляет загрузку шаблонов к другим загрузчикам:

При поиске шаблона Twig будет пробовать каждый загрузчик по очереди и он будет возвращаться как только шаблон найдется. При рендеринге шаблона index.html из вышеуказанного примера, Twig будет пытаться загрузить его с помощью $loader2, но base.html будет загружен из $loader1.

Twig_Loader_Chain принимает любой загрузчик, который реализует Twig_LoaderInterface .

Вы также можете добавить загрузчики с помощью addLoader() метода.

Создайте свой собственный загрузчик

Все загрузчики реализуют Twig_LoaderInterface:

В качестве примера, так выглядит встроенный Twig_Loader_String:

Метод isFresh() должен вернуть true, если текущий шаблон в кэше еще свежий, учитывая время последнего изменения или false в противном случае.

C Twig 1.11.0 можно также реализовать Twig_ExistsLoaderInterface, чтобы сделать ваш загрузчик быстрее при использовании с цепочкой загрузчиков.

Использование расширений

Расширения Twig - это пакеты, которые добавляют новые функции в Twig. Использование расширений так же просто, как с помощью метода addExtension ():

Twig поставляется в комплекте со следующими расширениями:

Расширения сore, escaper и optimizer не нужно добавлять к среде Twig environment, так как они выставлены по умолчанию.

Встроенные расширения

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

Прочитайте главу о расширении Twig чтобы узнать, как создавать свои собственные расширения.

Расширениe ядра

Расширения ядра определяет все основные особенности Twig:

Расширение Escaper

Расширение escaper добавляет автоматическое сохранение вывода в Twig. Это определяет тег autoescape и фильтр raw.

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

Если установлено HTML, все переменные в шаблонах будут сохранены (с помощью HTML стратегии сохранения), за исключением тех, которые используют фильтр raw:

Вы также можете изменить режим сохранения локально с помощью тега autoescape (смотрите autoescape документ для синтаксиса, используемого до Twig 1.8):

Правила сохранения реализуются следующим образом:

Литералы (целые числа, логические значения, массивы, . ) используются в шаблоне непосредственно как переменные или аргументы фильтра, которые никогда не сохраняются автоматически:

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

Сохранение применяется перед печатью, после любого другого фильтра:

Грубый фильтр следует использовать только в конце цепочки фильтров:

Автоматическое сохранение не применяется, если последний фильтр в цепочке помечен как безопасный для текущего контекста (например, html или js). escape и escape('html') отмечен безопасным для HTML, escape('js') отмечен безопасным для JavaScript, raw отмечен безопасным для всего остального.

Обратите внимание, что автосохранение имеет некоторые ограничения, такое как сохранение, применимое для выражений после вычисления. Например, при работе с конкатенацией, не дает ожидаемого результата, так как сохранение применяется к результату конкатенации, а не к отдельным переменным (так, raw фильтр не будет никак влиять здесь).

Расширение Sandbox

Расширения «песочницы» могут быть использованы для оценки небезопасного кода. Доступ к небезопасным свойствам и методам запрещен.

Безопасность «песочницы» регулируется policy instance. По умолчанию Twig обладает лишь одной классовой политикой: Twig_Sandbox_SecurityPolicy. Этот класс позволяет внести в «белый» список некоторые тэги, фильтры, значения и методы:

С такими настройками вы можете использование лишь тег if и фильтр upper. Кроме того, шаблоны будут способны вызывать только методы getTitle() и getBody() в объекте Article а title и body становятся общедоступными свойствами. Все остальные методы и свойства будут запрещены, и при обращении к ним будет генерировать Twig_Sandbox_SecurityError исключение.

Объект policy является первым аргументом конструктора Sandbox:

По умолчанию режим Sandbox отключен и его следует включить, когда включается ненадежный код шаблона тега sandbox:

Вы можете изолировать все шаблоны передавая true как второй аргумент для конструктора расширения:

Расширение оптимизации

Расширение optimizer оптимизирует древо узлов до компиляции:

По умолчанию все оптимизации включены. Вы можете выбрать те, которые вы хотите активировать путем передачи их в конструктор:

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

При создании разметки сайта, как известно, у нас есть элементы страниц сайта, которые, за редким исключением, присутствуют постоянно – это заголовок сайта, подвал и меню. Эти элементы нужно вынести в отдельные файлы (header.php, footer.php, menu.php).

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

На практике это выглядит следующим образом. Нам необходимо создать HTML файл, назовем, например main_layout.html:

В разметке нами был создан блок с названием content. Здесь мы подошли еще к одному важному понятию, которое существует в Twig – наследование шаблонов. Т.е. любой файл с разметкой – шаблон, который наследуется от main_layout.html может реализовать (заполнить произвольным содержимым) этот блок content, который отображается на данном месте в разметке. С помощью данного механизма, у нас есть возможность многократного использования шаблона, без необходимости переписывать в нем что-либо. Вернемся к нашему примеру. Главный файл index.html теперь можно написать подобным образом:

Как вы можете видеть файл index.html расширяет main_layout.html и добавляет в него блок content, который содержит таблицу сотрудников.

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

Кэширование

Конечно, разделение шаблона на отдельные части, упрощает понимание его назначения, но у подобного рода операций есть своя цена. Они плохо отражаются на производительности. Поэтому чтобы, Twig шаблоны не компилировались бы каждый раз разумно их кешировать. Объект Environment как раз может помочь нам в этом. Вот как:

Для того, чтобы кеширование в Twig заработало, нам нужно передать в конструктор класса Environment массив с параметром cache, которому нужно поставить в соответствие ту директорию, в которой будут находиться скомпилированные шаблоны. При последующих запросах, Twig будет отдавать уже скомпилированные шаблоны, таким образом, этап разбора и компиляции шаблона будет пропущен. Но, запомните, что в папке для кеширования лежат именно скомпилированные шаблоны, которые затем будут выполнены. Т.е. там не лежат html-файлы с разметкой, как можно было бы подумать.

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

Если Вы не хотите пропустить новые материалы на сайте,
то Вы можете подписаться на обновления: Подписаться на обновления

Если у Вас остались какие-либо вопросы, либо у Вас есть желание высказаться по поводу этой статьи, то Вы можете оставить свой комментарий внизу страницы.

Порекомендуйте эту статью друзьям:

Если Вам понравился сайт, то разместите ссылку на него (у себя на сайте, на форуме, в контакте):

Она выглядит вот так:

Комментарии ( 1 ):

Русскоязычная документация по Twig - PHP шаблонизатору. Руководство по Твиг на русском языке

Создание условной разметки

Работа с Ajax означает, что одно и то же содержание иногда выводится на экран как есть и иногда снабжается разметкой. Поскольку названия шаблонов разметки Twig могут быть любым допустимым выражением, вы можете передавать переменную, которая принимает значение true, когда запрос сделан через Ajax и вы можете выбрать, соответственно, разметку:

Создание динамических включений

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

Если var принимает значение index, то шаблон index_foo.html будет переведен. По сути дела, название шаблона может быть любым допустимым выражением, таким как следующее:

Замещения шаблона, который является саморасширяющимся

Шаблон может быть настроен двумя разными способами:

Inheritance (наследование): Шаблон расширяет родительский шаблон и переопределяет несколько блоков.
Replacement (замещение): Если вы используете загрузчик файловой системы, Twig загружает первый шаблон, который он находит в списке сконфигурированных каталогов; шаблон, найденный в каталоге, замещает другой из каталога, идущий далее по списку.

Но как вы скомбинируете оба: замену шаблона, который также расширяется (как шаблон в каталоге следующий в списке)? Давайте предположим, что ваши шаблоны загружены из . /templates/mysite и . /templates/default в этом порядке. Шаблон page.twig, сохраняемый в . /templates/default гласит:

Вы можете заменить этот шаблон, вставив файл с таким же названием в . /templates/mysite. Если вы хотите расширить исходный шаблон, вы возможно хотели написать следующее:

Конечно, это не сработает, поскольку Twig будет всегда загружать шаблон из . /templates/mysite.

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

Настройка синтаксиса

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

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

Вот пример конфигурации, который воспроизводит синтаксис некоторых других шаблонных механизмов:

Использование свойств динамического объекта

Когда Twig обнаруживает переменную article.title, он пытается найти общедоступное свойство title в объекте article.

Это также работает, если свойство не существует, но довольно таки определяется динамически, благодаря магическому методу __get(); вам просто нужно также применить магический метод __isset(), как показано на следующем отрывке кода:

Получения доступа к родительскому контексту во вложенных циклах

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

Результат будет схож с:

Во внутреннем цикле переменная используется loop.parent для того, чтобы получить доступ к внешнему контексту. Таким образом, индекс текущего topic, определенный во внешнем для цикла, доступен через переменную loop.parent.loop.index.

Определение неопределенных функций и фильтров на лету

Когда функция (или фильтр) неопределена, Twig по умолчанию выдает исключения Twig_Error_Syntax. Однако он может также вызвать callback (любую доступную PHP вызываемую), который должен вернуть функцию (или фильтр).

Для фильтров обратные вызовы регистра с registerUndefinedFilterCallback(). Для функций используйте registerUndefinedFunctionCallback():

Если вызываемый не способен вернуть допустимую функцию (или фильтр), он должен вернуть false.

Если вы регистрируете более чем один обратный вызов, Twig будет вызывать их по очереди пока он не вернет false.

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

Проверка шаблона на валидность

Когда код шаблона поддерживается третьим лицом (например, через веб- интерфейс), может быть интересным проверить синтаксис шаблона перед тем, как сохранить его. Если код шаблона хранится в переменной $template, вот как вы можете сделать это:

Этот метод не будет обнаруживать нарушения политики песочницы, потому что политика осуществляется во время рендеринга шаблонов (поскольку Twig нуждается в контексте для некоторых проверок, таких как разрешенные методы на объект).

Обновление измененных шаблонов когда APC включена и apc.stat = 0

При использовании АРС с apc.stat , установленном на 0, и включенном кэше Twig , очистка кэша не будет обновлять кэш АРС. Чтобы обойти эту проблему, можно расширить Twig_Environment, и вызвать обновление кэша АРС, когда кэш Twig переписывает кэш:

Повторное использование с сохранением состояния Node Visitor

При присоединении к экземпляру Twig_Environment, Twig использует его чтобы посетить все шаблоны, которые он компилирует. Если вам необходимо иметь в наличии информацию о состоянии, то вы вероятно захотите сбросить ее при посещении нового шаблона.

Этого можно легко достигнуть с помощью следующего кода:

Использование именованного шаблона для установки дефолтного экранирования

Данный функционал требует Twig версии 1.8 или выше.

Опция autoescape определяет использовании стратегии сохранения по умолчанию, когда никакого сохранения не применяется для переменной. Когда Twig используется, чтобы главным образом генерировать файлы HTML, вы можете установить его на html и явно поменять его на js, когда вы имеете несколько динамических файлов JavaScript благодаря тегу autoescape:

Но если вы имеете много файлов HTML и JS, и если ваши имена шаблонов следуют некоторым соглашениям, вы вместо этого можете определить стратегию сохранения по умолчанию, основанную на имени шаблона. Скажем, что имена ваших шаблонов всегда оканчиваются на .html для файлов HTML, а .js для таковых JavaScript и .css для таблиц стилей, то вот как вы можете конфигурировать Twig:

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

Хранение шаблонов в базе данных

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

Для начала, давайте создадим временную базу данных в памяти SQLite3 чтобы в дальнейшем с ней работать:

Мы создали простую таблицу templates, которая размещает два шаблона: base.twig и index.twig.

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

И, наконец, вот пример того, как вы можете ее использовать:

Использование различных частей шаблона

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

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

В предыдущем уроке админки мы разобрались с конфигами и значениями параметров. Сегодня научимся выводить настройки в браузере. А чтобы не было скучно просто писать html, подключим к проекту шаблонизатор Twig. Ему и будет посвящена основная часть статьи.

У Twiga отличный функционал и простой синтаксис. В дебри лезть не будем, нам хватит и малой части его возможностей. Начинаем.

Подключаем Twig и рендерим первый шаблон.

Ищем твигу местечко в проекте. Создадим папку admin/lib/Twig и закинем туда библиотеку. Идеально, смогли и без composer-a.

Идем дальше. Твигу нужна папка cache, куда он может свободно записывать отрендеренные шаблоны. Дискуссионный вопрос, куда определяют папку кэша нормальные пацаны? Я без фантазии создал прямо в admin - admin/cache. Ну и бог с ней. Главное, убедитесь, что в нее разрешена запись юзеру www-data. Если сидите на винде, то пофиг. А если нет, то смените владельца и дайте права на запись в cache

Последнее, что нужно твигу - знать, где брать шаблоны. Для этого сделаем папку admin/templates и закинем в нее index.html c содержимым Hello, >. Ага, уже постигаем магию. Значение name будет передаваться в шаблон извне, из php-файла.

Давайте в admin/index.php подключим twig и отрендерим шаблон. Испокон веков автор фигачил разметку в index.php, а сейчас нет. Повзрослел. php-файл займется тем, чем и должен - логикой приложения. Даже звучит приятно, значит, пора реализовывать.

В первой строке подключаем сам твиг. Дальше инициализация. В документации я прочитал, если возникнет Непредвиденный Случай и почему-то НЕ СРАБОТАЕТ, то напишите Twig_Autoloader::register();
Я человек-удача и тот самый случай поймал. Написал, что велено, и все стало хорошо. Надеюсь, Вам повезет больше и вместо 10 строк уложитесь в 9.

Дальше в $loader и $twig загружаем среду или что-то такое нужное для шаблонизатора. Указываем в параметрах путь к папкам шаблонов и кеша и важный параметр debug=true. На боевом сайте debug убирайте, но пока оставьте. Иначе при изменении шаблона в templates/index.html твигу будет наплевать и он сразу возьмет срендеренный из кэша. И будем удивляться, чо это шаблон правим, а в браузере не меняется.

Итак, обновим страницу и видим текст Hello, Twig. Поздравляю, наш первый шаблон отработал. Но прежде чем наполнять его полезным содержимым, немного изменим index.php. А точнее подключим класс админки и в шаблон отдадим не name=Twig, а настройки. Получится вот так.

Редактируем шаблон.

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

Конечно, форма будет на bootstrap. Однажды я раздуплюсь и покажу какой-нибудь другой css-фреймворк, но пока лень. Оправдываю себя тем, что мы же с вами не css-ы верстаем, а ПРИЛОЖЕНИЯ ПРОГРАММИРУЕМ. Пока отмазка работает, возвращаемся к шаблону.

Заготовку беру с сайта bootstrap. В head скопипастим такое

А body придется писать самим.

Выглядит как обычная бутстраповская форма, но с твиговскими вставками.
Разберем по очереди.

Перебираем в цикле настройки и для каждой выводим label и input в форме.

item.key используется и как айди, и как название name инпута, и как значение for в label. Такой важный нужный key.
item.title - заголовок настройки.

А это текстовое поле со значением.

Теперь обновляем страницу и видим список настроек с нужными значениями. Красота! Поменяйте значения полей в config/values.json. Работает, опять красота.

На этом позитивном предложении автор закончил бы статью, но нельзя. Потому что внимательный читатель скажет: стоп, а картиночка-то не та! С прототипом не сходится. А любознательный читатель еще и спросит: а зачем в первом уроке столько мутили с конфигами и разными типами данных? Чтобы сейчас выводить их тупо в инпуты? Конечно, читатель прав. Поэтому автор сходит выпить чаю и напишет еще пару абзацев.

Итак, продолжаем. Мы хотим выводить разные инпуты-селекты в зависимости от типа найстройки. В этом помогут условия twig и поле type из конфига настроек. В наличии 4 типа настроек: text, number, checkbox и select. Под каждую из них делаем условие. Вместо

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

текстовый инпут просто обернули в условие item.type == 'text'
number - тот же инпут, только с type="number"
для checkbox отдельная верстка. Логично, чекбокс же, не просто инпут.
Не забываем про атрибут checked, который ставится в зависимости от item.value (true или false).
Интересно, что у самого чекбокса нет атрибута name со значением item.key. Зато name есть у скрытого инпута рядом с чекбоксом.
Спойлер: так удобнее для отправки формы на бекенд, в следующей статье убедимся.
у select-а есть цикл, потому что выводим список возможных значений из поля item.list

Теперь еще раз обновим страницу. У меня получилось так

Вот теперь все. Можно поиграть с настройками и значениями в json-файлах и посмотреть, как оно успешно раскидывается по формочке.

Следующий урок будет заключительным по теме "админка на файлах". Мы напишем js-код, который отправит данные на бекенд, и php-код, который эти данные сохранит. Бонусом внедрим уведомления, чтобы пользователь видел, не забыл ли он нажать кнопочку сохранить.

Читайте также: