PHP и Twig создание шаблонов веб страниц


Содержание

Как вставить свой php код на сайт, который создан на шаблонизаторе Twig

на сайт, который создан на Twig.
Файл куда надо запихнуть код -> sidebar.twig, но php там понятное дело не работает. Подскажите куда надо залезть, чтобы создать свой макрос или как правильно это называется?

Добавлено через 2 часа 40 минут
Я хочу вставить код от sape на сайт.
этот код

05.08.2020, 20:51

Как вставить свой php-код в новую страницу
здравствуите скачал WordPress (Version 3.3.1), я ветом цмс-е полнии нуб, вот что не понял: в.

Как посадить свой домен на свой сайт, который на домашнем компе?
У меня статический ip. на картинке видно что сейчас в настройках, в качестве записи A указал.

как найти в jquery элемент, который создан в цикле php
вот у меня бд с пользователями. и код у меня таков : $mes=mysql_query(«SELECT * FROM `messages`.

Применение внешней функции обработки текста в шаблонизаторе Twig
Добрый вечер. Короче у меня есть функция для определения мультиязычности пример .

Вставить php-условие в html-код, который находится в php-коде
Выводится список из базы данных foreach($callbacklist as $call) < .

Как в Twig использовать шаблон в зависимости от ситуации?

Имеется несколько Twig шаблонов, и страница где нужно их выводить в зависимости от значения переменной. Но Twig почему то игнорирует условия и использует последний подключенный шаблон, в данном примере «template2.twig».

  • Вопрос задан более года назад
  • 233 просмотра

Получилось решить проблему простым вложением.

Есть файл layout.twig в нем базовый шаблон, далее файл index.twig в нем шаблон страницы, и отдельные файлы для каждого из микрошаблонов.

Ну и template1.twig например:

Ну и на страницу рендерим template1.twig.

Как создать расширение с помощью Twig

Я использую Apache и PHP на Ubuntu 17.04
Я использую веточку. Я установил Twig вот так.

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

Вот пример index.php, который создает массив каталогов, а затем отображает его с помощью файла files.html.twig, расположенного в каталоге шаблонов.

вот файлы .html.twig, он расширяет «base.html.twig»

и base.html.twig содержит основную оболочку с панелью навигации и нижним колонтитулом. Это все работает, как ожидалось.

Прямо сейчас у меня есть basebar в моем base.html.twig, это просто HTML, где я должен редактировать элементы.

Я сделал функцию php для получения массива navbar, который работает в шаблоне (navbar.html.twig), но проблема в том, что я должен включить или включить эту функцию php на каждой странице, которую я создаю. Я хочу, чтобы мой шаблон navbar.html.twig получал массив из функции php напрямую.

Я считаю, что мне нужно создать расширение ветки (функция php) и зарегистрировать его. Я прочитал документы по этому вопросу (кажется, все для полной установки Symfony, я использую только веточку).

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

  1. где поставить мою функцию php? Могу ли я просто создать папку с именем extensions и поместить туда файл navbar-list-funtion.php?
  2. где зарегистрировать функцию, чтобы ее можно было вызывать из шаблона? в какой-то документации сказано зарегистрироваться в app / config / services.yml (у меня нет этого файла или каталога)
  3. после того, как я поместил функцию php в распознанное место, затем зарегистрировал ее правильно, … как я буду вызывать возвращенный массив в шаблоне navbar.html.twig?

Решение

Если вы не используете фреймворк, такой как Symfony, это немного изменится в зависимости от того, как вы справляетесь с этой ситуацией. Я сам использую пространства имен в своем проекте, чтобы включить автозагрузку с помощью composer. Моя древовидная структура просто следует моему пространству имен, например My/Project/Twig/Extensions

«Лучший» способ продлить Twig с помощью Twig_Extension учебный класс
Просто поместите новый файл в созданные вами папки с соответствующим именем

нота: Как с Twig 2.X функция getName() больше не является обязательным

Мой / Проект / Twig / Extensions / ProjectTwigExtension.twig

Используя класс расширения, вы можете легко сгруппировать все свои функции / фильтры / узлы / глобалы / … После того, как вы создали этот класс, все, что вам нужно сделать, это зарегистрировать класс внутри Twig , Поскольку я не знаю специфики, вам нужно посмотреть в своем проекте, где вы делаете

Для регистрации класса просто используйте следующую строку,

Как вы можете, класс расширения имеет функцию getFunctions Здесь вы можете определить все функции, которые вы хотите.

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

    new Twig_SimpleFunction(‘twig_function_name’, array($this, ‘method’))

Будет вызывать функцию method внутри текущего класса расширения
new Twig_SimpleFunction(‘twig_function_name’, ‘trim’)

Вызовет глобальную функцию trim


new Twig_SimpleFunction(‘twig_function_name’, array($obj, ‘method’))

Будет вызывать функцию method экземпляра $obj
new Twig_SimpleFunction(‘twig_function_name’, array(‘MyClass’, ‘method’))

Будет вызывать статическую функцию method от MyClass
new Twig_SimpleFunction(‘twig_function_name’, function($arg1, $arg2) < // . ; >)

Создание сайта с помощью движка шаблонов PHP Twig

Я прочитал документацию для веточка, но я не совсем понимаю, как соединить точки.

допустим, я создаю файл index.php Что делает Twig_Loader_Filesystem и Twig_Environment классы. Я могу загрузить один шаблон здесь, используя loadTemplate() .

содержимое отдельной страницы хранится в .phtml или .html.twig файлы, которые могут ссылаться на другие страницы сайта. Однако они всегда будут связаны с другими .php-файл, а не шаблон.

что является ли лучший способ абстрагировать этот процесс, так что мне нужен только один файл php для нескольких шаблонов? Реврайт? Какой-то класс маршрутизаторов? Есть ли примеры?

1 ответов

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

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

использование

Я собираюсь предположить, что у вас есть структура каталогов, подобную это:

создать папки в корневой сервер реж ( /home/www в данном случае):

поместите файлы шаблонов под templates каталог

теперь пример индекса.файл php:

другие файлы PHP будут похожи.

Примечания

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

Использование шаблонизатора Twig в 1С-Битрикс

Шаблоны Bitrix — мощнейший инструмент кастомизации вашего сайта. Однако, подход, выбранный Bitrix сильно отличается от принятого в современных фреймворках. Но мало кто знает (а еще меньше используют), что Bitrix позволяет использовать шаблонизаторы в шаблонах компонентов (да-да, шаблон сайта придется писать по-старому). Сегодня мы рассмотрим один из простейших вариантов работы.

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

Для нашего небольшого эксперимента нам потребуется веб-сервер с PHP на борту (я использую OpenServer), Composer в качестве пакетного менеджера и минимальные навыки работы в консоли.

Установка Composer тривиальна. Идем на сайт https://getcomposer.org/, переходим в раздел Download и следуем простым инструкциям. Для пользователей Windows все сводится к скачиванию и установке Composer-Setup.exe и последовательному копипасту четырех команд в консоль:
Для более удобной работы с Composer, я создам bat-файл:
…и помещу в него вызов composer.phar:
Теперь вместо длинной записи «php composer.phar» можно будет использовать сокращенную «composer».

Дальше нам необходимо задать некоторые настройки Composer. Дело в том, что по умолчанию, все пакеты зависимостей будут установлены в директорию /vendor. Мне это не нравится. Все дополнительные библиотеки я хочу видеть в папке /local/php_interface/lib/ и подключать их в init.php.

К счастью, пакетный менеджер позволяет легко это настроить. Создадим в корне сайта файл composer.json:
И зададим нужную нам директорию таким вот образом:
Теперь можно выполнить команду добавления зависимости Twig в проект и произвести установку:
Готово. После завершения установки в директории local/php_interface/lib/ должны появиться папки composer, twig и файл autoload.php.
Autoload.php необходимо подключить в init.php для работы всех установленных с помощью composer пакетов:
Теперь напишем обработчик. Для начала опишем в глобальной переменной $arCustomTemplateEngines список расширений и функцию-обработчик.
Ну и опишем саму функцию-обработчик (в том же init.php). Функция принимает в себя все данные, с которыми работает шаблон. Из интересного тут: задание папки хранения кеша и его сброс при нажатии на Битриксовскую кнопку «Сбросить кеш». Остальное тривиально и описано в Basic API Usage на сайте Twig.
Давайте начнем экспериментировать. Добавим на тестовую страницу компонент списка новостей и настроим на вывод какого-нибудь инфоблока:

Скопируем дефолтный шаблон и назовем его twig_test
Вот наша структура шаблона:
Смотрим, любуемся, а теперь берем и удаляем файл template.php. Вместо него создаем файл template.twig. Вот код файла template.twig целиком:
Судя по моим наблюдениям, twig с включенным кешированием не уступает в скорости шаблонам Bitrix с включенным композитом. Цифры примерно такие.

Шаблоны Bitrix + Кеш + Композит:
Twig + Кеш:
Как итог: шаблонизаторы в Bitrix использовать можно. Как минимум, это избавит разработчиков от вредной привычки получать данные в шаблоне компонента.

Передача переменных в Twig шаблон.

Простая html-разметка внутри нашего шаблона Twig — это, конечно, хорошо, но на самом деле возможности шаблона Twig намного шире.

Одно из самых главных преимуществ для чего это нужно — это передача внутрь этого шаблона каких-то переменных.

Давайте посмотрим, как можно значение какой-то php переменной перенести внутрь шаблона Twig, который мы создали.

Давайте вернемся к контроллеру и внутри него создадим какую-нибудь временную переменную $tmp.

Переменная передается в шаблон как второй параметр для функции render.

Этот второй параметр обычный ассоциативный массив.

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

Таким образом, данные, которые имеются внутри контроллера, были переданы внутрь Twig шаблона. Разметка у нас в шаблоне получилась статичной, а данные внутри являются динамичными. Они изменяются и зависят от того, какое состояние имеет php функция.

Чтобы оставить сообщение, зарегистрируйтесь/войдите на сайт через:

Или зарегистрируйтесь через социальные сети:

Админка на файлах. Урок 3. Шаблонизатор Twig

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


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

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

Хотел скачать последнюю версию twig-a 2.x, но обломался. Он ставится через composer, а я в нем не шарю. Подозреваю, что composer мало чем отличается от фронтовых npm или bower, но погружаться сейчас не будем. Кто в теме, сделают composer require «twig/twig:^2.0» и без меня, а я как нормальный php-шник скачиваю версию 1.x через Download zip и не парюсь. Качать отсюда https://github.com/twigphp/Twig/tree/1.x

Ищем твигу местечко в проекте. Создадим папку 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. Под каждую из них делаем условие. Вместо

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

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

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

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

Если прониклись твигом и хотите узнать больше, то вот документация на русском. https://x-twig.ru/intro/

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

Наследование шаблонов в PHP без использования сторонних библиотек

При разработке Web-приложений мы обязательно сталкиваемся с проблемами рендеринга HTML-страниц. Обычно эти проблемы решает шаблонизатор — собственно PHP или какой-нибудь парсер шаблонов. Если приложение большое и страницы содержат множество блоков, то сложность шаблонов может резко возрасти, а у разработчиков появляется желание упростить работу с ними. В ход идут разные техники, но обычно это выделение в шаблонах повторяющихся блоков и правильная их декомпозиция — включая наследование шаблонов.

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

Похоже этот подход нравится не только мне и разработчикам Django, но и Fabien Potencier автору фреймворка Symfony и шаблонизатора Twig. Twig обладает множеством интересных функций, включая компиляцию шаблонов в нативные PHP-классы, фильтрацию данных, встроенными циклами и т.д. — в общем всем тем, что полагается иметь современному шаблонизатору. Но самое интересное — это то самое наследование шаблонов, о котором я говорил выше. Вот пример из официальной документации:

В базовом шаблоне определены основные блоки, а в дочернем — пример их переопределения. Копания в исходных кодах показало, что реализуется это наследование также нативно — путем наследования “скомпилированных” классов. Отличная идея! Все хорошо, но меня несколько смущала необходимость изучения пусть простого, но все-таки отличного от PHP синтаксиса шаблонизатора. А моя нелюбовь к ненативным шабонам началась еще со Smarty (в котором тоже есть наследование) и до сегодняшнего дня не претерпела существенных изменений.

Совсем близко к иделу подошел разработчик из Сан-Франциско Adam Shaw. Очевидно, он также как и я не любит эксперименты с синтаксисом шаблонизаторов и придумал незамысловато названную библиотеку Template Inheritance На сайте жирным по желтому написано, что «There is no need to learn another template language», мол не нужно учить другой язык шаблонов. С этим я согласен. Что же он предлагает? Смотрим пример опять же из официальной документации:

Синтаксис натуральный, блоки выделены явно, подключил библиотеку в базовый шаблон и забыл. Все. Автор говорит, что сделал это с помощью буферов и стека (возможны вложенные блоки). Код действительно интересный, но пестрит наличием глобальных переменных. Чего же остается ещё желать?

Вот здесь-то мы и подходим к главной теме нашего повествования. А не сможет ли PHP сам переопределить блоки базового шаблона? Я думаю, что вполне! Смотрите:

Вот базовый шаблон:

Здесь в 3 блоках шаблона проверяется наличие соответствующей переменной, хранящей некоторый контент и, если она присутствует в области видимости, то ее можно выводить в шаблон, а если нет, то выводится контент по-умолчанию. Нам остается только переопределить эти переменные в дочернем шаблоне. А вот собственно и он:

В этом примере переопределяется переменная $content, если она не была установлена заранее. Это сделано для того, чтобы была возможность наследовать этот шаблон и переопределить блок контента. Думаю, идея понятна. Не требуется никаких библиотек — просто пишите шаблоны в таком стиле и будет вам счастье.

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

Эта функция возвращает вывод шаблона из файле $pathToTemplate с подстановкой переменных, полученных из массива $data. extract — на любителя — можно и не делать, а обращаться напрямую к $data. Перед выводом из контента убираются начальные и конечные пробелы. В шаблоне можно делать все, что позволит делать ваша совесть, не нарушая принципы разделения логики и представления, и PHP. Например, в зависимости от ситуации подключать тот или иной базовый файл.

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


Читают сейчас

Похожие публикации

  • 20 октября 2020 в 00:32

Запускаем PHP-скриптики через php-fpm без web-сервера. Или свой FastCGI-клиент (под капотом)

Небезопасные функции PHP

Шаблоны Django. Наследование.

Вакансии

AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Комментарии 58

Я не сторонник шаблонизаторов, но вот это:

Ужасно. Куда лучше выглядит:

P.S. Поправьте «за ранее», сильно режет глаза.

Элементарно в шаблонизаторе (если он есть).

А если надо очень сложную логику, пишется напрямую.

Есть такая метод/функция, назовём её render или show
При вызове render(‘content’); выводится переменная content либо (если она пустая или необъявлена) результат работы функции (назовём её так, это по сути не совсем функция, может быть методом класса, шаблоном, неважно) content()
При этом, если вызвать print $users->show(), то она вернёт готовый HTML код. Вот примерный пример:

Таким образом, начиная от main() и заканчивая users#show, все контроллеры запускают код, затем рендерят шаблон и возвращают результат, что позволяет использовать значение, возвращённое функцией контроллера для дальнейшей обработки, например, вывода в лайоуте.
Далее, в контроллере лайоута (т.е. у меня HMVC, каждый слой содержит вложенные) основной разметки, вызывается (псевдокод)

И в шаблоне вывода лайоута (который выполняется после этого кода) запускается render(‘content’). Т.е. будет выведена переменная, если по каким-либо причинам её нет, запустится функция.
Внутри content() есть свои контроллеры и шаблоны, при этом, если там будет запущено

, то это даст возможность переопределить переменную footer, если её нет, то всё возьмётся из шаблона footer.html.
Также в шаблоне content() может быть следующая конструкция

Она работает через тот же самый буфер. HTML-подобные теги выбраны для подсветки парных тегов через IDE.
Что при вызове переопределит переменную footer. Таким образом из вложенного шаблона (например, основного содержимого) можно переопределять внешний. Явный минус в том, что всё, что можно переопределить — в разных файлах.
Описал немного сумбурно, без соблюдения используемого синтаксиса, но суть такова: вначала вызываем то, что вложено, в переменные записываем результаты, в лайоуте их используем.
Чего тут нет — вызова не функции а сразу фрагмента на месте, как в примере статьи.

Сейчас почему то считается стыдным на хабре писать про свои реализации и велосипед

Вам не кажется, что это просто не профессионально? Что гораздо лучше было бы написать статью про разбор внутренностей того же самого twig’a, про его недостатки и плюсы, про его альтернативы и чем они лучше/хуже. Таким образом статья будет действительно полезной и профессиональной.

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

Хабр — место для того, чтобы делиться знаниями.

Да, использовать самописные шаблонизаторы в крупных проектах с фиксированными сроками часто бывает непрофесиональным.

Но мне кажется непрофессиональным не уметь написать шаблонизатор (подобный тому, что в посте, а не какую-нибудь ересь) и уметь пользоваться twig-ом.

Лично мне немного жаль, что на хабре мало тем, посвящённым шаблонизаторам, реализациям ActiveRecord, собственным велосипедам, ибо мне эта тема жутко интересна.

Дело вот в чем. Хабр читают люди разного уровня. Думаю, что для кого-то пост будет полезен. И уже почему-то более 60 человек добавили его в избранное. Значит, действительно это кому-нибудь было нужно.

Я часто вижу, как делаются представления в проектах — это либо include header & include footer либо 2-уровневый шаблон с layout и с шаблоном контента. Мне не нравятся оба подхода. Первый — за то, что в каждый файл дублирует подключения блоков. Второй — за то, что content обычно весь body, а если не весь, то теряется гибкость или приходится иметь несколько layout.

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

Подобный поход я применял, когда рефакторил «унаследованный» «спагетти»-код, где вообще шаблонов не было — каждая из 50+ страниц начиналась с и т. д., то есть даже мелкое изменение основной вёрстки приводило к необходимости менять 50+ страниц. Выглядело у меня примерно так:

А layout.php практически такой же как у вас. Правда до необходимости трехуровневого наследования не доходило, потому в наследниках layout.php не было проверки типа isset($content);

P.S. В шаблонах мне больше нравится альтернативный синтаксис if (. ):… endif чем if (. ) <… >^)

Дело вот в чем. Хабр читают люди разного уровня.

Я часто вижу, как делаются представления в проектах — это либо include header & include footer либо 2-уровневый шаблон с layout и с шаблоном контента. Мне не нравятся оба подхода. Первый — за то, что в каждый файл дублирует подключения блоков. Второй — за то, что content обычно весь body, а если не весь, то теряется гибкость или приходится иметь несколько layout.

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

А что вы имеете ввиду под partials?

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

а все проверки осуществлять в классе шаблона. Нужно будет попробовать. Но тогда мы придем почти к PHP TI, только с объектами. А идея простая, но честно говоря не вижу чем она сильно плоха кроме не сильно лаконичного синтаксиса.

Ещё один пример.
Взять рельсы — всё здорово, но если пропробовать создать банальную форму обратной связи стандартными методами.
Для добавления валидаций приходится создавать модель. А это значит, что механизмы, заточенные на базу данныех, надо переопределять, чтобы они писали письмо вместо создания нового письма в базе данных. Просто так прикрутить валидатор уже как-то неровно получается.
Потому и рельсы не подходят для многих других задач.
Ещё примеры форм, где нужна валидация, но модель, записывающая данные не нужна:
Авторизация пользователя
Поиск по каталогу с валидацией формы поиска
Ввод имени, капчи, и последовательный переход на скрытую страницу после этого.

Это что касается рельс.
Дальше допустим Yii.

Для загрузки библиотек, использующих namespace по соглашению PSR-0 (например, Zend Framework 2 или Symfony2) необходимо сначала зарегистрировать корень библиотеки как псевдоним пути.


Для примера попробуем использовать Imagine. Скорируем директорию Imagine в protected/vendors. Ну и само использование:

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

Это что касается Yii.
Ну много таких моментов можно найти — и тем интереснее писать своё.

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

1) Готовое, оттестированная многими программистами ядро, которое просто работает
2) Если у вас большой проект и вы берете нового человека и он знает фреймворк, то его не надо обучать
3) Если у вас что-то не работает, вы нашли баг или что-то не так — issue на гитхабе обычно решает все Ваши проблемы довольно оперативно, в итоге вы занимаетесь работой, а не написанием и тестированием своего велосипеда
4) Огромное к-во расширений на любой вкус и поддержка комьюнити

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

Да не везде велосипед, конечно. В качестве базового фреймворка я в последнее время использую Slim, а в качестве ORM php.activerecord. Использую я их потому, что они мне идеологически близки, и я понимаю, почему авторы сделали так, а не иначе.

Что же касается Symfony2, то мы в компании сделали на ней пробный проект, чтобы понять, что это такое. И честно говоря — отгребли кучу проблем — скорее всего идеология разработчиков не совсем совпадает с нашими представлениями. Очевидно, что мы просто не научились ее готовить. Но честно говоря, я не хочу с ней связываться после этого. А как я смогу написать что-то хорошее, если мне не нравится инструмент?

Конкретно про формы я могу сказать следующее — пока я не нашел ничего, что соответствовало бы моим запросам. Symfony Forms довольно близки к идеалу. Но как добавить в нее собственные контролы? И таких мелочей очень много.

Кстати, не подскажете, может быть знаете какие-нибудь альтернативы для обработки форм? Мне нужно, чтобы я создал класс для формы, добавил в нее объекты контролы, засунул в них объекты валидаторы, и все это использовал бы в контроллере как в Symfony. Есть такая штука — phorms. Но мне не нравится качество исходников, активность разработки и некоторые архитектурные решения.

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

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

Симфони, Yii — для стартапов и блогов вроде myshows.ru, bash.org.ru хороши. По этой же причине такие вещи не делают на джумлах. Каждой задаче — своё решение.

Но вот чтобы быть админками — генераторами админок встроенными не обойтись. Текстовые странциы должны создаваться за минуту, новости за пять минут, каталог за 10. И это с УЖЕ рабочей, более менее и готовой для преподнесения клиенту админкой, а не с формой авторзации на сайте с ссылками на формы редактирования с кучей валидаций.

И о велосипедах. Если он достаточно качественен (а такое бывает), и сайты на нём создаются быстрее хотя бы в 3-4 раза, чем на популярных фрейморках, и новые сотрудники обучаются сходу за пару часов (ведь это не Zend с талмудами документаций), то причин не использовать не вижу. Особенно, когда являешься автором, занешь её от корки до корки, и можешь реализовывать вещи, для реализации которых на популярных фреймфорках придётся очень даже попотеть.
К тому же, если самописный фреймфорк имеет много внедрений, документацию, открыт, имеет issues на гитхабе, имеет ряд готовых модулей, имеет сообщество, примеры, видеоуроки, развивается уже давно, то где грань между самописными и не-самописными? Наличие сообщества? Тогда Joomla — лучший в мире фреймфорк.
Документация и поддержка? Тогда bitrix лучший в мире.
Профессионализмом, тестами, объёмом и количеством разработчиков? Тогда Zend лучший в мире.

Да, ктото напишет своё. Будет хуже, будет меньше оттестировано и сообщество меньше. Это всё не цели разработки. А цели — делать проекты быстро, очень быстро, чтобы работало качественно, багами не сыпало.

Этот разговор будет вечным, всегда все пишут одно и тоже, и всегда одно и тоже отвечают.

Нет, конечно, надеюсь что не путаю.
Фреймфорком я называю систему, каркас, где есть роутер, готовый механизм контроллеров, моделей, шаблонизатор либо возможность использовать внешний, валидаторы, ActiveRecord, скаффолдинг, ряд прикладных функций для упрощения жизни и возможность подключения внешних библиотек из того же Zend. В таких системах нет таблиц mos_tables или mos_catalogs_ids или mods_users_options_system_goods, только users, clients, comments, что позволяет легко получать доступ из кода к любым данным и быстро.
На таких системах легко строить свякого рода CRM-системы, ToDo — листы, опросники, сайты знакомств, системы вроде хабрахабра.
CMS/CMF (либо проще — админка) я называю систему, где можно дать возможность легко создать страницу, дать возможность редактировать всё, что надо администратору сайта, легко добавить какой нибудь текстовый блок на главную, запилить новости на сайте за 5 минут (в моей получается только за десять, могу скринкаст показать), какую нибудь галерею и так далее.

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

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

Поэтому — велосипед, используется классическое MVC, упрощённое дальше некуда (чтобы не было ситуации подобной UMI.CMS, когда для создания банальной формочки приходится изучать API создания модулей, городить семь файлов, прописывать её в качестве модуля и так далее.
То есть по образцу классических фреймфорков создаётся контроллер, шаблоны, модуль, выводится, а заботы по редактированию всего этого берёт на себя админка. Системных таблиц для CMS в классическом понимании вообще нет, только pages, news, catalogs, users — по названиям создаваемых моделей — админке как таковой это не мешает, зато на низком уровне данные запрашивать — самое то. По сути, конечно, админка, в которой можно сделать триаду MVC и её использовать.

Другой вариант — написать такую на кодеигнитере например, или ActiveAdmin в рельсах. Но вот те, которые я встречал, сами те ещё велосипеды, превращающие кодеигнитер в, извините, какашку, что ругаются не только программисты, но и саи администраторы сайта (заказчики). А это уже критично.

Как запустить php-код в файле шаблона Twig [duplicate]

У меня есть do_shortcut, и мне нужно встроить его в шаблон ветви. Я попытался выполнить код в файле php my-code.php:

Далее, на странице twig over.twig:

Но не Работа. Любое предложение? Спасибо.

3 ответа

Попробуйте этот код:

О части include , создайте файл my_code.html.twig в приложении / Resources / views / my_code.html.twig и скопируйте свой код с my-code.php

. Затем вы можете включить это код в любом месте:

Twig для дизайнеров шаблонов. ч.1

Эта статья описывает синтаксис и семантику шаблонизатора и будет наиболее полезна тем, кто создает на Twig шаблоны.

Краткий обзор
Шаблон — суть простой текстовый файл. Он может генерировать любой тексто-ориентированный формат (HTML, XML, CSV, LaTeX и др.). У него нет особенного расширения, .html или .xml вполне подойдут.
Шаблон содержит переменные или выражения, которые заменяются значениями, когда шаблон запускается, и тэги, которые контролируют логику шаблона.
Вот минималистичный шаблон, который иллюстрирует основные принципы. Детали мы обсудим в этой статье чуть позже.

Существует два вида разделителей: <% . %>и << . >> . Первый используется для выполнения утверждений типа «петля», второй выводит результат выражения в шаблон.

Интеграция в IDE
Современная IDE поддерживает подсветку и автозаполнение для большого диапазона языков. Поскольку синтаксис Twig схож с шаблонами Jinja и Django, IDE, поддерживающая эти две системы, написанные на Python, должны также поддерживаться в Twig.
Если вы используете Textmate, вы также можете использовать связки Jinja или Django.
Если вы используете Vim, вы можете использовать и Jinja syntax plugin.

Переменные
Приложение пропускает переменные в шаблон, так что вы можете ничего не делать в самом шаблоне. Переменные могут иметь в себе атрибуты или элементы, к которым тоже можно получить доступ. Как выглядит переменная, во многом зависит от приложения, из которого она берется.
Вы можете использовать точку (.) для получения доступа в атрибуты переменной или альтернативный вариант — так называемый «индекс» синтаксиса ([]). Следующие строчки выполняют те же функции:

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

Реализация
Для удобства foo.bar делает то же самое в PHP слое:

  • проверьте, является ли foo массивом, а bar — действующим аргументом
  • если нет, и если foo является объектом, проверьте, что bar — допустимое свойство
  • если нет, и если foo является объектом, проверьте, что bar — допустимый метод (даже если bar — конструктор — используйте __construct() вместо него)
  • если нет, и и если foo — объект, проверьте, что getBar — допустимый метод
  • если нет, и если foo — объект, проверьте, что isBar — допустимый метод
  • если все еще нет, возвращайте нулевое значение.

С другой стороны, foo[‘bar’] работает практически так же с небольшой разницей в порядке:

  • проверьте, является ли foo массивом, а bar — допустимым элементом
  • если нет, возвращайте нулевое значение.

Использование альтернативного синтаксиса также весьма полезно для динамического получения свойств из массивов:

Twig всегда ссылается на следующие переменные:

  • _self: ссылается на текущий шаблон;
  • _context: ссылается на текущий контекст;
  • _charset: ссылается на текущую кодировку.

Фильтры
Переменные могут быть модифицированы при помощи фильтров. Фильтры отделяются от переменных вертикальной чертой (|) и могут иметь необязательные аргументы в круглых скобках. Множественные фильтры могут быть связанными. Выходные данные одного фильтра могут применяться к следующему.
<< name|striptags|title >>, например, будет удалять все HTML тэги и заглавные буквы в них. Фильтры, принимающие аргументы, имеют круглые скобки вокруг них, как вызов функции. Этот пример присоединит список запятыми: << list|join(',') >>.
Раздел о встроенных фильтрах ниже описывает все встроенные фильтры.

Комментарии
Для того, чтобы закомментировать часть строки в шаблоне, используйте синтаксис комментариев <# … #>. Это удобно для комментирования части шаблона в целях отладки или для добавления информации для других дизайнеров шаблонов, или для себя:

Контроль пробелов
Первый символ новой строки после тэга в шаблоне автоматически удаляется (как в PHP). Кроме этого, пробелы не изменяются шаблонизатором, так что каждый из них (длинный пробел, таб, новые строки) вернется в неизмененном виде.
Используйте тэг spaceless для удаления пробелов между HTML тэгами:

Игнорирование
Иногда необходимо, чтобы Twig проигнорировал части шаблона, которые в другом случае он бы обработал их как переменные или блоки. Например, если используется синтаксис по умолчанию, а вы хотите применить << как необработанную строку в шаблоне и не вызывать переменную, вам придется использовать уловку.
Самый легкий способ — применить переменную разделителя, используя переменное выражение:

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

Наследование в шаблонах
Самая мощная часть в Twig — наследование в шаблонах. Оно позволяет вам построить базовый «скелет» шаблона, который будет содержать все общие элементы вашего сайта и определять блоки, которые можно переписывать дочерним шаблонам.
Звучит сложно, но это одна из основополагающих черт Twig. Легче будет понять на примере.

Цукерберг рекомендует:  Vuforia - Unity (ошибка с vuforia)
Понравилась статья? Поделиться с друзьями:
Все языки программирования для начинающих