Микрофреймворк Slim PHP


Содержание материала:

Популярные PHP-фреймворки для веб-разработчиков

Содержание:

Язык PHP (Hypertext PreProcessor, «препроцессор гипертекста») неслучайно называют самым мощным и популярным инструментом веб-разработки. Благодаря лёгкости в освоении, свободному распространению ПО и высокой адаптивности, он применяется сегодня для производства любых программных продуктов.

PHP используется в 80% интернет-сайтов Всемирной сети. В том числе, в таких мега-проектах, как Facebook, Wikipedia и Google. На нём основано больше половины современных систем управления контентом (CMS), включая популярнейшую WordPress.

Полноценную работу с PHP сложно представить без одного из основных инструментов PHP-разработки — фреймворков. С этой технологией эффективность и скорость создания сайтов и приложений увеличивается в разы.

В данном обзоре мы кратко рассмотрим общие принципы выбора платформы и расскажем про лучшие PHP-фреймворки.

Что такое фреймворк

Фреймворк (framework, «каркас», «конструкция») — это динамически пополняемая библиотека языка программирования, в которой собраны его базовые модули. Фреймворки создаются для упрощения процессов разработки приложений, сайтов, сервисов. Чтобы не писать модуль в приложении с нуля, гораздо проще обратиться к готовым шаблонам фреймворков, которые и формируют рабочую среду разработчика.

Фреймворки есть у каждого языка программирования — Java, JavaScript, Python, Ruby, PHP. Но именно PHP-фреймворки занимают почётное место главного инструмента бекэнд-разработки.

Достоинства PHP-фреймворков

  • Производительность. Фреймворки ускоряют разработку. Например, PHP-фреймворк избавляет вас от необходимости писать запросы к базам данных. В фреймворках реализованы базовые функции CRUD, которые необходимы для работы с базами данных.
  • Масштабируемость. Написанные на фреймворках приложения легко масштабируются.
  • Удобство. Код фреймворков лаконичный, поэтому с ним просто работать. Поддерживать легче проект на фреймворке, чем на нативном PHP.
  • Простота. В PHP-фреймворках используются шаблоны проектирования (например, MVC). Это значительно упрощает разработку, делая процесс быстрее.
  • Безопасность. Приложения на фреймворках лучше защищены, чем приложения на чистом PHP.
  • Экономичность. В фреймворках реализован принцип DRY. Это позволяет разработчикам писать меньше кода.

Как выбрать

Какой именно PHP-фреймворк окажется самым подходящим зависит от масштабов и целей проекта. При выборе подобной платформы следует обратить внимание на ряд базовых показателей.

  1. Насколько широк и гибок функционал фреймворка. Есть ли в нем всё, что может потребоваться для текущего проекта.
  2. Легко лиосвоить фреймворк. С учётом уровня штатного (фриланс) разработчика.
  3. Скорость и современность — насколько фреймворк ориентирован на прогрессивные методы программирования. Например, есть ли поддержка объектно-ориентированного метода.
  4. Как масштабируется проект, созданный на фреймворке. Есть ли возможность написать структурируемый код для масштабируемых приложений.
  5. Как часто выпускаются обновления и имеется ли у фреймворка активно действующее сообщество.
  6. Существует ли у фреймворка сервис гарантированной долгосрочной поддержки релизов (LTS).
  7. Есть ли поддержка архитектуры MVC (Model ViewController / Модель-представление-контроллер).

Рейтинг фреймворков

Laravel

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

Особенности Laravel

  • Хорошо структурированная и подробная документация. На русском языке она доступна сразу на двух источниках: laravel.ru и laravel.su.
  • Структура кода основана на архитектуре MVC.
  • Собственная консоль Artisan для работы с базовыми элементами фреймворка — миграциями, авторизацией, контроллерами и моделями.
  • Собственный шаблонизатор Blade, который даёт возможность использовать код PHP в представлениях, но при этом не тормозит работу фреймворка.
  • Установка jQuery и BootStrap по принципу «из коробки». Скомпилированные пакеты после установки можно найти в файлах app.js и app.css.
  • Есть валидаторы — структуры проверки и данных по определённым правилам, позволяющие генерировать собственные шаблоны правил.
  • Удачно реализован принцип инверсии управления (IoC).
  • Лидер по количеству доступных расширений (пакетов). Сегодня их насчитывается более 9 000.

Yii

Обектно-ориентированный PHP-фреймворк Yii считается лидером по способности обеспечить производительность и часто выбирается для высоконагруженных приложений. С момента первого релиза в 2008 году, фреймворк непрерывно развивался в течении многих лет. Yii часто попадает в топ фреймворков PHP, благодаря сильно развитому сообществу пользователей, значительная часть которых — русскоговорящие.

Особенности Yii

  • Гибкие механизмы генерирования исходного кода.
  • Полноценная реализация парадигмы MVC.
  • Интерфейсы работы с БД — DAO и ActiveRecord.
  • Есть функция полного или частичного кеширования страниц.
  • Присутствует возможность оперативного моделирования прототипа проекта для предпродажной демонстрации заказчикам.
  • Как и Laravel, поддерживает установку с помощью пакетного менеджера Composer.
  • Быстрая генерация кода с помощью браузерного элемента Gii.

CodeIgniter

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

Особенности CodeIgniter

  • Поддержка архитектуры MVC, а так же БД MySQL, PostgreSQL, MSSQL, SQLite, Oracle..
  • Возможность добавления сторонних плагинов для расширения функционала приложения.
  • Фреймворк обладает предустановленными библиотеками с обширнейшим функционалом.
  • Возможность использовать сторонние и самописные библиотеки (с помощью менеджера Sparks) позволяет системе быстро масштабироваться.
  • Есть возможность установки дополнений поддержки модульности (HMVC).
  • CodeIgniter располагает подробной документацией по платформе, что позволит новичкам быстрее его освоить.

Symfony

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

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

Особенности Symfony

  • Собственный обработчик шаблонов Twig позволяет создавать чистый код и дополнять функционал PHP.
  • Можно установить с помощью Composer.
  • Большое количество доступных для установки расширений.
  • Поддержка дополнительных форматов: PHP, YAML и XML.
  • Совместимость с Codeception облегчает написание тестов.
  • Использование реляционного проектора Doctrine позволяет работать на более продвинутом уровне.
  • Стал основой для многих популярных CMS (Magento, Drupal, Opencart).
  • Активное сообщество пользовательской поддержки.

Phalcon PHP

Полнофункциональная PHP-инфраструктура, в которой реализованы шаблоны проектирования веб-приложений с использованием архитектуры МVC. С момента появления в 2012 году, Phalcon был написан на языке С и С++. В данное время поддерживается и версия, переписанная на Zephir.

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

Особенности Phalcon

  • Основа всех компонентов — язык программирования C.
  • Взаимодействие с БД основано на технологии ORM.
  • Есть поддержка наиболее распространённых ОС — Linux, Windows, Mac.
  • Высокое быстрродействие, благодаря прямому взаимодействию фреймворка с внутренним структурам PHP.
  • Высокая производительность при минимальных ресурсных затратах и необходимых файловых операциях.
  • Стал основой для других популярных фреймворков — Kohana и Rain Framework.

CakePHP

Легкий стиль и элегантный код являются сильными сторонами этого «программного каркаса». Фреймворк характеризуется как простая и легкая в изучении среда, благодаря использованию оптимизированной системы CRUD. CakePHP будет оптимальным решением для создания визуально впечатляющих и функциональных сайтов.

Особенности CakePHP

  • Полная совместимость с PHP4 и PHP5.
  • Удобное взаимодействие с БД через встроенный ORM (Object-Relational Mapping).
  • Поддержка большого числа плагинов и СУБД (PostgreSQL, MySQL, SQLite).
  • Создание приложений по принципу скаффолдинга — на основе структуры БД.
  • Есть разделение фреймворка на основные компоненты (коллекции, валидация, утилиты, события, ядро), которые можно использовать независимо друг от друга.
  • Обширная документация и активное сообщество.

Zend Framework

Гибкая методология делает возможным разработку высококачественных корпоративных веб-приложений. Один из основных минусов PHP-фреймворка — сложность в изучении, вероятно отпугнет новичков. Однако, преимущества объектно-ориентированного способа программирования и расширяемая функциональность с интеграцией внешних библиотек стоят того, чтобы уделить изучению Zend более пристальное внимание.

Особенности Zend Framework

  • Многофункциональная, компонентная, объектно-ориентированная платформа с MVC архитектурой.
  • Полная E_STRICT-совместимость всех компонентов фреймворка.
  • Много встроенных библиотек, позволяющих легко взаимодействовать со сторонними приложениями.
  • Несвязанные компоненты можно повторно использовать в других приложениях.
  • Высокая степень интернационализации.

Fuel PHP

Это гибкий и полнофункциональный PHP-фреймворк, который начали разрабатывать в 2011, а официальный запуск произвели в 2014 году. Отличается тем, что на платформе используется собственная архитектура MVC, называющаяся иерархической — HMVC.

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

Особенности Fuel PHP

  • Многофункциональная, компонентная, объектно-ориентированная платформа с MVC архитектурой.
  • Присутствует собственная иерархическая архитектура HMVC.
  • Маршрутизация ссылок с повышенной защитой от уязвимостей и кэширование.
  • Поддержка PHP версии 5.4 и выше.
  • Собственная утилита командной строки.

PHPixie

Позиционируется как современный, быстрый и безопасный PHP-фреймворк с архитектурой HMVC. Первый выпуск был представлен в 2012 году. Он был предназначен для создания высокопроизводительных платформ под сайты формата read-only («только для чтения»).

К функциональным возможностям PHPixie относят реализацию валидации ввода, возможности авторизации, аутентификацию и кэширование. Из минусов можно отметить недостаточную развитость поддержки и малочисленность сообщества.

Особенности PHPixie

  • Лёгкий движок, позволяющий обеспечить высокую скорость приложений.
  • Основан на стандартах PSR-2 и PSR-4. Поддерживает библиотеки для работы с PSR-7 запросами.
  • Шаблонизатор с поддержкой наследования и блоков.
  • Удобный ORM, работающий на основе разбивки логики запросов.
  • Большая база документации и хорошая реализация API.

Slim Framework

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

Это простой PHP-фреймворк отлично подойдёт для небольшого проекта, который не подразумевает обязательное использование других фреймворков. В функционал включены: URL маршрутизация, шифрование сеансов и cookie, HHTP кэширование и многое другое.

Особенности Slim Framework

  • Максимально простой фреймворк с понятным и удобным интерфейсом.
  • Быстрое подключение одним файлом.
  • Сохраняет хорошую производительность, даже при работе одновременно с несколькими задачами.
  • Поддерживает библиотеки для работы с PSR-7 запросами.


Вывод

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

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

А какой PHP-фраймворк используете вы? За какие качества вы его выбрали? Делитесь в комментариях ниже!

Чтобы фреймворк работал на пределе своих возможностей — выбирайте быстрый и надёжный VPS от Eternakhost.

Микрофреймворк slim

25 апреля 2020 года свет увидела новая мажорная alpha -версия микрофреймворка Slim, а 18 мая она выросла до beta . Предлагаю по этому поводу ознакомиться с новой версией.

  • О новшествах фреймворка
  • Написание простого приложения на Slim-4
  • О дружбе Slim и PhpStorm

Новое в Slim 4

Основные нововведения по сравнению с версией 3:

  • Минимальная версия PHP — 7.1;
  • Поддержка PSR-15 (Middleware);
  • Удалена реализация http-сообщений. Устанавливаем любую PSR-7 совместимую библиотеку и пользуемся;
  • Удалена зависимость Pimple. Устанавливаем свой любимый PSR-11 совместимый контейнер и пользуемся;
  • Возможность использования своего роутера (Раньше не было возможности отказаться от FastRoute);
  • Изменена реализация обработки ошибок;
  • Изменена реализация вывода ответа;
  • Добавлена фабрика для создания экземпляра приложения;
  • Удалены настройки;
  • Slim больше не устанавливает default_mimetype в пустую строку, поэтому нужно установить его самостоятельно в php.ini или в вашем приложении, используя ini_set(‘default_mimetype’, ») ;
  • Обработчик запроса приложения теперь принимает только объект запроса (в старой версии принимал объекты запроса и ответа).

Как теперь создать приложение?

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

Теперь конструктор приложения принимает следующие параметры:

Параметр Тип Обязательный Описание
$responseFactory PsrHttpMessageResponseFactoryInterface да PSR-17 совместимая фабрика серверного http-запроса
$container PsrContainerContainerInterface нет Контейнер зависимостей
$callableResolver SlimInterfacesCallableResolverInterface нет Обработчик вызываемых методов
$routeCollector SlimInterfacesRouteCollectorInterface нет Роутер
$routeResolver SlimInterfacesRouteResolverInterface нет Обработчик результатов роутинга

Так же теперь можно воспользоваться статическим методом create фабрики приложения SlimFactoryAppFactory .
Этот метод принимает на вход такие же параметры, только все они опциональные.

Верните мне 404 ошибку!

Если мы попробуем открыть несуществующую страницу, получим код ответа 500 , а не 404 . Чтобы ошибки обрабатывались корректно, нужно подключить SlimMiddlewareErrorMiddleware

Middleware

Промежуточное ПО теперь должно быть реализацией PSR-15. В качестве исключения, можно передавать функции, но сигнатура должна соответствовать методу process() интерфейса PsrHttpServerMiddlewareInterface

Сигнатура ($request, $response, $next) больше не поддерживается

Как жить без настроек?

Без настроек жить можно. Предоставленные инструменты нам в этом помогут.

httpVersion и responseChunkSize

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

Сейчас эти функции можно возложить на эмиттер ответа.

Подключаем к приложению

outputBuffering

Данная настройка позволяла включать/выключать буфферизацию вывода. Значения настройки:

  • false — буфферизация выключена (все вызовы операторов echo , print игнорируются).
  • ‘append’ — все вызовы операторов echo , print добавляются после тела ответа
  • ‘prepend’ — все вызовы операторов echo , print добавляются перед телом ответа

Разработчики фреймворка предлагают заменить эту опцию промежуточным ПО SlimMiddlewareOutputBufferingMiddleware , в конструктор которого передается PSR-17 совместимая фаблика потока и режим, который может быть равен append или prepend

determineRouteBeforeAppMiddleware

Эта настройка позволяла получить текущий маршрут из объекта запроса в промежуточном ПО

На замену предоставляется SlimMiddlewareRoutingMiddleware

displayErrorDetails

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

Помните SlimMiddlewareErrorMiddleware ? Оно и здесь нас выручит!

addContentLengthHeader

Данная настройка позволяла включать/отключать автодобавление заголовка Content-Length со значением объема данных в теле ответа

Заменяет опцию промежуточное ПО SlimMiddlewareContentLengthMiddleware

routerCacheFile

Теперь вы можете напрямую установить файл кеша роутера

Создание приложения на Slim-4

Чтобы более подробно рассмотреть фреймворк, напишем небольшое приложение.

Приложение будет иметь следующие роуты:

  • /hello/ — страница приветствия;
  • / — редирект на страницу /hello/world
  • Остальные роуты будут возвращать кастомизированную страницу с 404 ошибкой.

Логика будет в контроллерах, рендерить страницу будем через шаблонизатор Twig
Бонусом добавим консольное приложение на базе компонента Symfony Console с командой, отображающей список роутов

Шаг 0. Установка зависимостей

  • микрофреймворк, slim/slim;
  • реализация интерфейса контейнера (PSR-11) psr/container;
  • реализация интерфейсов http-сообщений (PSR-7) psr/http-message;
  • реализация интерфейсов фабрик http-сообщений (PSR-17) psr/http-factory;
  • шаблонизатор twig/twig;
  • консольное приложение symfony/console.

В качестве контенера зависимостей я выбрал ultra-lite/container, как легкий, лаконичный и соответствующий стандарту.
PSR-7 и PSR-17 разработчики Slim предоставляют в одном пакете slim/psr7. Им и воспользуемся

Предполагается, что пакетный менеджер Composer уже установлен.

Создаём папку под проект (в качестве примера будет использоваться /path/to/project ) и переходим в неё.

Добавим в проект файл composer.json со следующим содержимым:

и выполним команду

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

Если работаем с git, добавим файл .gitignore и внесем туда директорию vendor (и диреткорию своей IDE при необходимости)

Я использую IDE PhpStorm и горжусь этим . Для комфортной разработки самое время подружить контейнер и IDE.
В корне проекта создадим файл .phpstorm.meta.php и напишем там такой код:

Этот код подскажет IDE, что у объекта, реализующего интерфейс PsrContainerContainerInterface , метод get() вернёт объект класса или реализацию интерфейса, имя которого передано в параметре.

Шаг 1. Каркас приложения

  • app — код приложения. К нему мы подключим наше пространство имен для автозагрузчика классов;
  • bin — директория для консольной утилиты;
  • config — здесь будут файлы конфигурации приложения;
  • public — директория, открытая в веб (точка входа приложения, стили, js, картинки и т.д.);
  • template — директория шаблонов;
  • var — директория для различных файлов. Логи, кэш, локальное хранилище и т.д.
  • config/app.ini — основной конфиг приложения;
  • config/app.local.ini — конфиг для окружения local ;
  • app/Support/CommandMap.php — маппинг команд консольного приложения для ленивой загрузки.
  • app/Support/Config.php — Класс конфигурации (Чтобы IDE знала, какие конфиги у нас имеются).
  • app/Support/NotFoundHandler.php — Класс обработчика 404й ошибки.
  • app/Support/ServiceProviderInterface.php — Интерфейс сервис-провайдера.
  • app/Provider/AppProvider.php — Основной провайдер приложения.
  • bootstrap.php — сборка контейнера;
  • bin/console — точка входа консольного приложения;
  • public/index.php — точка входа веб приложения.

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

Микро-фреймворк как основа веб-проекта на PHP

Несколько лет назад я делал приватный проект, где было много математики и обработки данных. Поскольку хотелось сразу сделать правильно, то использовал ООП, классы, статические методы и ряд новых функций PHP 5.5. После того, как проект загрузили на «боевой» сервер, всё «разрушилось», поскольку там стояла PHP 5.2, которую (по каким-то особым причинам), нельзя было обновить. Код пришлось переписывать с учётом старой версии. Теперь, если сервер всё-таки обновят до PHP 7.x, код опять придётся переписывать, поскольку между версиями нет полной совместимости.

Не существует идеального и универсального решения для веб-проекта. Они все обязательно окажутся в тупике из-за изначально непродуманной архитектуры или объективных причин, вроде несовместимости между PHP-версиями. Даже если сделать как «по теории», в процессе развития проект окажется неспособным решить какие-то новые задачи, поскольку мы элементарно не можем предсказывать будущее. Единственным способом двигаться дальше будет только революционный подход, который подразумевает полную или частичную потерю совместимости со старым кодом.

Через это прошли все фреймворки, системы, библиотеки (любого ЯП) и т.п., которые продолжают развиваться. По мере роста, вначале идёт эволюционный подход, когда возможностей хватает, но потом резкий скачок к новой версии. Для того, чтобы упростить такие переходы, архитектура приложения должна изначально подразумевать такую «версионность».

За последние лет 10 накопился некоторый мировой опыт того, как грамотно разрабатывать веб-проекты. Например деление файлов на классы и модульность стало фактически «стандартом». Однако проблема в том, что архитектура проекта как правило строится только исходя из предполагаемых потребностей конечных пользователей.

Примеры с файлами вы найдёте в конце статьи.

Возьмём например Laravel, который содержит массу библиотек: авторизация, база данных, работа с почтой, кэширование, логирование и т.д., и т.п. Или Symfony с десятками компонентов. CodeIgniter 4, который выглядит более скромно, но тоже с десятками библиотек и хелперов.

Во всех php-фреймворках сотни или даже тысячи классов, которые могут быть связаны между собой самых причудливым образом. И это речь ещё не идёт о полноценных CMS, которые «навешивают» ещё «тонну» своего кода.

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

Поэтому лучший фреймворк — тот, который позволяет выходить за рамки своих правил.

Нельзя так же не отметить, что существующие php-фреймворки (не все, но многие) обладают явно излишней функциональность и объёмом (шутка ли — дистрибутивы до 30Мб!). Например в CodeIgniter 4 есть замечательный модуль Honeypot, который даже непонятен по своему назначению. Или Format, который предназначен для форматированного вывода JSON или XML-данных. Потребность в таких вещах равна нулю, но команды разработчиков продолжает «пилить» такой код, в надежде «а вдруг кому-то когда-то пригодится!». 🙂

Собственно, здесь мы подходим к мысли, что архитектура веб-проекта должна базироваться на чём-то значительно более мелком — микро-фреймворке. Главное его назначение в том, чтобы предоставить лишь только тот код, который будет использоваться в самом микрофрейворке. При этом он должен быть 100% рабочим и самодостаточным, где без труда можно вывести «Hello, World!».

Какова должна быть минимальная функциональность микро-фреймворка?

Конечно же, это будет зависеть от самого веб-проекта, возможно какой-то модуль может оказаться критически важным, но если говорить о чём-то «типовом», то потребуется решить всего несколько задач.

  • организация каталогов
  • базовый автозагрузчик классов
  • поддержка Composer’а
  • поддержка (файлов) конфигурации
  • единая точка входа для сайта и приложения

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

Единая точка входа

Здесь всё достаточно просто: корневой index.php. Этот файл — эдакий диспетчер, который формирует лишь начальные константы для путей, а дальше уже подключает начальное ядро фреймворка.

Из приведенного кода видно, что само приложение будет располагаться в каталоге app, а фреймворк в system. Такое деление полезно тем, что позволяет легко обновлять код фреймворка, не затрагивая приложение. При этом, мы можем совершено произвольно переименовать эти каталоги или поменять их расположение.

«Точка подключения» фреймворка

Файл system/core/bootstrap.php является первым, где можно определить другие константы, базовые функции и т.д. Прежде чем регистрировать автозагрузчик, нужно решить где будут располагаться основные модули фреймворка. Для простоты, будем придерживаться модульной структуры, описанной в прошлой статье. Получится например так:

Сам по себе микрофреймворк не будет использовать ни Composer, ни module, ни lib, но «full»-фреймворку они скорее всего потребуются. Поэтому мы заранее определяем их расположение. От этого будет зависеть код автозагрузчика (вы его найдёте в готовых файлах к статье).

Разделение фреймворка и приложения

Теперь нужно определить что должно быть в каталоге приложения app. С моей точки зрения, этот каталог должен быть как можно «свободней», чтобы не ограничивать веб-разработчика. Например, если предполагается админ-панель, то она может быть в app/admin. Излишняя строгость со стороны фреймворка создаёт совершенно бесмысленное усложнение каталогов. Например в CodeIgniter волей-неволей, приходится использовать жёстко заданные controllers и views, что в итоге меня вынудило использовать отдельный каталог maxsite для файлов MaxSite CMS.

Сложность в том, что фреймворк (уровень «system») должен как-то использовать файлы приложения (уровень «app»), чтобы корректно выполнить свою работу (например подключить БД).

Поэтому должен быть специальный каталог в app о котором будет знать фреймворк. Например app/framework. В этом каталоге могут размещаться файлы конфигураций, роутинга и т.п.

В system/core/bootstrap.php будет происходить подключение файлов конфигурации приложения, а в конце происходит переход к файлу app/app.php. Важный момент здесь в том, что существует явная цепочка подключаемых файлов:

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

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

Файл app/app.php нужен для того, чтобы на уровне приложения можно было бы реализовать его произвольную логику. Фреймворк ничего не должен знать о том, как устроенно веб-приложение. Это может быть примитивная landing page, сложная CMS или вообще backend под какое-то API. После того, как управление перешло к этому файлу, вся работа целиком ложится на приложение.

Роутинг

Роутинг — неотъемлемая часть любого веб-проекта. Поэтому почти все фреймворки предлагают какой-то свой готовый вариант, которому приходится следовать. Но, на самом деле, роутинг — это уровень приложения. Эта «горькая истина» обычно постигается когда уже поздно что-то менять в проекте. На роутинг завязывается ЧПУ (хотя бы в виде .htaccess) и, если мы говорим о каком-то универсальном варианте, то они должны комплексно настраиваться на уровне самого приложения, поскольку потребности и задачи у всех совершенно разные.

Более того, ЧПУ может в конечном итоге настраиваться самим пользователем.

Многие фреймворки не просто «навязывают» свой роутинг, но и не могут сами без его работать. Просто приведу пару примеров, чтобы было понятно о чём речь. Например: Slim, Flight, Fat-Free Framework и другие. Такие фреймворки практически не годятся для проектов с произвольными адресами, особенно теми, которые назначает конечный пользователь. Такой типичный подход реализован в стареньком фреймворке с забавным названием Limonade, где всё крутится возле функции dispatch . То есть просто не получится сделать ни единой страницы приложения, пока не будет прописаны правила роутинга.

Когда правила формируются на уровне самого приложения, то нет никаких проблем — ваше приложение и вам решать какие будут адреса. Но если это уровень фреймворка, то придётся строго следовать его идеологии и загонять себя в жёсткие рамки.

Модули приложения

На уровне «system» мы предусмотрели расположение модулей, библиотек и файлов Composer’а. Аналогично нужно сделать и для «app», для тех случаев, когда нужно «расширить» возможности фреймворка. Лучшее место, конечно же app/framework. В этом случае фреймворк самостоятельно организует автозагрузку классов, причём можно сделать даже с приоритетом приложения. Тогда можно будет использовать «перезагрузку» system-классов.

Функции микрофреймворка

Как правило фреймворки содержат множество готовых для использования функций. Речь именно о функциях, а не php-классах. В CodeIgniter есть даже отдельный вид — хелперы (helpers). Кажется, что это круто, но на самом деле такая практика порочна, поскольку не просто бессмысленно раздувает код, ни и часто дублирует то, что уже есть в PHP. Если стоит задача получить какой-то функционал, то он должен быть оформлен именно как модуль. Для простоты можно вообще использовать статические методы. «Голые» функции нужны на уровне приложения, поскольку с ними проще работать. Например при выводе html-кода в шаблоне удобней простая функция, чем класс — это и меньше кода и более высокая читабельность. Но вот на уровне самого фреймворка функции не стоит создавать, или ограничиться лишь теми, которые использует сам фреймворк.

То есть не нужно создавать лишних сущностей.

Уровень «public»

Некоторые фреймворки предлагают размещать «system» и «app» на уровень выше чем каталог «public_html», что делает их недоступными при прямом url-обращении. С точки зрения безопасности, наверное такое решение может использоваться, но на практике оно не очень удобно и скорее всего бессмысленно.

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

Создаётся впечатление, что разработчики фреймворков просто не в курсе, что современный WEB — это и возможность быстрой смены шаблона (читай дизайна и функциональности), то есть то, что реализуется в любой CMS. Когда мы начинаем использовать уровень «не-public» возникает довольно серьёзная проблема разделения шаблона на такие же уровни. Решить её, естественно, можно, только можно и не создавать проблему на ровном месте. 🙂

Что в итоге

В целом получается такая структура:

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

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

Микрофреймворк Slim PHP

Slim is a PHP micro-framework that helps you quickly write simple yet powerful web applications and APIs.

It’s recommended that you use Composer to install Slim.

This will install Slim and all required dependencies. Slim requires PHP 7.1 or newer.

Choose a PSR-7 Implementation & ServerRequest Creator

Before you can get up and running with Slim you will need to choose a PSR-7 implementation that best fits your application. A few notable ones:

  • Slim-Psr7 — This is the Slim Framework PSR-7 implementation
  • Nyholm/psr7 & Nyholm/psr7-server — This is the fastest, strictest and most lightweight implementation available
  • Guzzle/psr7 & http-interop/http-factory-guzzle — This is the implementation used by the Guzzle Client, featuring extra functionality for stream and file handling
  • zend-diactoros — This is the Zend PSR-7 implementation

Slim-Http is a set of decorators for any PSR-7 implementation that we recommend is used with Slim Framework. To install the Slim-Http library simply run the following command:

The ServerRequest and Response object decorators are automatically detected and applied by the internal factories. If you have installed Slim-Http and wish to turn off automatic object decoration then you can use the following statements:

Hello World using AppFactory with PSR-7 auto-detection

In order for auto-detection to work and enable you to use AppFactory::create() and App::run() without having to manually create a ServerRequest you need to install one of the following implementations:

  • Slim-Psr7 — Install using composer require slim/psr7
  • Nyholm/psr7 & Nyholm/psr7-server — Install using composer require nyholm/psr7 nyholm/psr7-server
  • Guzzle/psr7 & http-interop/http-factory-guzzle — Install using composer require guzzlehttp/psr7 http-interop/http-factory-guzzle
  • zend-diactoros — Install using composer require zendframework/zend-diactoros

Then create file public/index.php.

You may quickly test this using the built-in PHP server:

Going to http://localhost:8000/hello/world will now display «Hello, world».

For more information on how to configure your web server, see the Documentation.

To execute the test suite, you’ll need to install all development dependencies.

Please see CONTRIBUTING for details.


Learn more at these links:

If you discover security related issues, please email [email protected] instead of using the issue tracker.

Slim is part of Tidelift which gives software development teams a single source for purchasing and maintaining their software, with professional grade assurances from the experts who know it best, while seamlessly integrating with existing tools.

This project exists thanks to all the people who contribute. Contribute.

Become a financial contributor and help us sustain our community. Contribute

Support this project with your organization. Your logo will show up here with a link to your website. Contribute

The Slim Framework is licensed under the MIT license. See License File for more information.

Slim micro-framework — кто работает с ним?

Всем здравствуйте.
Решил вот покопаться с этим микрофреймворком.
Ну и поставил третью версию через composer, всё встало хорошо, нет проблем.
Запускаю скрипт hello-word (взятый прямо из мануала) — не работает. Убираю параметр — роутинг проходит. Вернул параметр назад, запускаю и из браузера, и из консоли — нет результата.
Точнее есть, но ошибочный. С параметром — «404», без параметра — «PHP Notice: Undefined index: name. » в логе (но это как раз и понятно, так и должно быть).

Ладно, думаю. Откатил на версию 2.0
Точнее, третью полностью снёс, вторую по новой установил. Аналогичный результат.

Скрипт стандартный (для версии 2.0):

Угрохал на этот hello-word целый вечер. Ничего не сделал.
Господа, может, кто подскажет — где тут проблема?

Slim framework

by admin · 9 марта 2012

После работы с Zend Framework в качестве эксперимента несколько простых проектов решил выполнить на микрофреймворке. Долго подбирал по обзорам и изучая код. Понравились больше всего, Sylex и Fat Free(F3). Но выбрал Slim. Основная причина — требования к php. Первые 2 требуют версию, не ниже 5.3. Slim работает начиная с версии 5.1.х. За что разработчику огромное спасибо. PHP версия от 5.3 стоит далеко не везде, как и не везде есть возможность запинать админа для обновления версии.

Что есть у Слима? Он оправдывает приставку микро. По сути есть минимум для построения контроллера в терминологии MVC и весьма примитивный View. И это все. Для использования в проектах, я добавил к нему шаблонизатор Twig и DbSimple 2.0.

Микрофреймворк Slim PHP

Практически любой веб-разработчик, даже начинающий, скорее всего, слышал или знаком с понятием фреймворк. Напомню, что фреймворк – это набор библиотек (функций и методов), или если сказать несколько иначе это каркас, будущего приложения, то есть веб-проекта, сайта или скрипта. При этом, фреймворк предлагает определенные методы, которые избавляют программиста от стандартной рутинной работы, к примеру создание точки входа на сайт, создание ЧПУ, организация работы с базой данных и т.д. Таким образом, фреймворк позволяет создавать приложения быстрее, эффективнее и безопаснее. И, как правило, все фреймворки обладают огромнейшим функционалом и возможностями. Но очень часто при разработке небольших проектов, весь функционал фреймворка попросту не нужен, вполне достаточно только неких базовых возможностей. В этом случае на помощь приходят микрофреймворки.

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

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

Урок 0. Курс по микрофреймворку PHP Slim

Урок 1. Введение в фреймворк PHP Slim. Установка

От автора: с данного урока мы начинаем цикл уроков, посвященный изучению микрофреймворка PHP Slim. Микрофреймворк – это набор библиотек (функций и методов), или если сказать иначе — каркас будущего веб-приложения, но значительно упрощенный, нежели полноценный фреймворк. То есть микрофремворк, состоит только из определенного программного ядра будущего сайта, скрипта или веб-проекта.

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

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

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

Урок 2. Настройки и режимы работы фреймворка PHP Slim

От автора: на прошлом уроке мы познакомились с микроофреймворком Slim, научились выполнять его установку, поговорили о принципе его работы и настроили перенаправление адресов, для формирования красивых ЧПУ. В данном видео, мы поговорим о настройках как стандартных, так и собственных — пользовательских, а также изучим режимы работы данного микрофреймворка.

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

Урок 3. Роутеры

От автора: в данном уроке мы поговорим о методах регистрации маршрутизаторов или роутеров для различных типов HTTP запросов. При этом определимся с такими понятиями как роутер, протокол HTTP, типы запросов, а также URI, URL и URN.

По итогам данного урока Вы узнаете, что такое роутер и процесс маршрутизации. Научитесь использовать методы микрофреймворка Slim, для создания и регистрации роутеров под различные типы HTTP запросов, а также увидите, как передавать переменные в ранее созданные роутеры.

Урок 4. Условия. M >

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

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

Урок 5. Группировка роутеров. Helpers

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

По итогам данного урока Вы научитесь формировать группы роутеров, увидите, в чем особенность методов из группы helpers и узнаете как самостоятельно сформировать код статуса протокола http, который, будет возвращен в качестве ответа от сервера.

Урок 6. Шаблонизатор Slim. Отображение данных на экран

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

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

Урок 7. Файловая структура CMS

От автора: изучив основные теоретические моменты в предыдущих уроках курса по микрофреймворку PHP Slim, мы приступаем к практике, и для закрепления пройденного материала, реализуем несложную систему управления контентом, используя инструменты микрофреймворка Slim. В данном уроке мы создадим файловую структуру будущего скрипта и определимся с логической схемой, создаваемой CMS.

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

Урок 8. Главный контроллер CMS

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

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

Урок 9. Доработка главного контроллера

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

По итогам данного урока мы закончим класс основного логического ядра будущей CMS, реализуем дополнительный контроллер, задача которого – формирование готового HTML кода общих элементов пользовательской части сайта. При этом Вы научитесь работать с переменными окружения микрофремворка Silm.

Урок 10. Главное меню сайта

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

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

Урок 11. Формирование общего шаблона пользовательской части

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

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

Урок 12. Список материалов главной страницы

От автора: приветствую Вас в курсе по микрофреймворку PHP Slim. Продолжаем реализацию несложной системы управления контентом, используя инструменты данного фреймворка. В данном уроке мы завершим функционал главной страницы будущей CMS, а именно отобразим в центральной области пользовательской части список материалов сохраненных в базе данных. При этом количество отображаемых материалов может быть велико, а значит выводить материалы необходимо “порционно”, используя постраничную навигацию, что собственно мы и сделаем в данном уроке.

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

Урок 13. Авторизация пользователей

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

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

Урок 14. Закрытый раздел CMS

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

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

Урок 15. Права групп пользователей

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

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

Урок 16. Главная страница админки. Страница добавления нового материала

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

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

Урок 17. Добавление нового материала

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

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

Урок 18. Финальная доработка CMS

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

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

Микрофреймворки на PHP

Андрей Синицын: Всем добрый день! Меня зовут Андрей Синицын. Я работаю в компании «Ontico». Расскажу вам про такую набирающую популярность вещь, как микрофреймворки на PHP.

Давайте сначала определим предметную область: о чем будем общаться? Микрофреймворк – это «каркас» приложения, включающий в себя какие-то роутеры и типовые задачи, которые уже решены. Ключевая часть слова здесь – «микро». Очень облегченный, очень маленький, очень быстрый продукт (не знаю, как назвать).

Что внутри?

Внутри есть, как правило, роутер, который определяет URL, базовая реализация MVC, модели, контроллеры, обработки HTTP-запросов, обработка ошибок. Это самый минимум, который необходим, чтобы быстро запустить приложение.

Как все это появлялось. Честно говоря, я познакомился с микрофреймворком не на примере PHP. Я увидел на Python: bottle.py. Очень понравилась сама идея – один файл, все очень здорово. Я решил покопать дальше и нашел, что на многих языках это реализовано.

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

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

Получалось очень много одинаковых вещей. Не хватало функциональности. Дальше у нас появились фреймворки, которые не навязывали разработчику свою структуру – решали типовые задачи. Огромное количество типовых задач закрыто во фреймворке, чтобы у разработчика не болела голова о том, что ему надо обрабатывать формы, следить за запросом, как-то cookie…

«Все включено». Сделали хорошую вещь по принципу «все включено». Отлично кастомизируется, но достаточно большой объем кода и требует более высокой квалификации, нежели накидать сайтик на WordPress или магазинчик на Joomla поднять.

В этот момент появились микрофреймворки.

Маленький и быстрый. Ключевая особенность – это именно маленький и быстрый. Нет ничего лишнего. Он очень быстро работает, очень хорошо выглядит для разработчика. Отлично интегрируются сторонние компоненты туда: он набивается по принципу конструктора. Туда набивается все, что необходимо, и быстро запускается.

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

Как это использовать?

Например, у нас есть хорошая соседка – кавайная няшечка, которую давно хочется пригласить в кафе. Она приходит и говорит: «Знаешь, я вот хочу открыть магазин по продаже вышитых мной платочков». Конечно, отличный повод познакомиться с девочкой!

Садишься за комп и в этот момент понимаешь, что WordPress – это не кошерно. Мы же крутые ребята, в принципе-то. Брать какой-нибудь Zend Framework, чтобы сделать ей три странички, тоже не хочется. Собственно говоря, чтобы не писать ничего с нуля, можно взять любой из микрофреймворков.

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

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

Особенности микрофреймворков

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

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

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

Есть такая особенность, что многие микрофреймворки требуют определенной версии PHP. Как правило, это больше 5.3, потому что там активно используется кодогенерация, пространства имен для разделения компонентов. PHP ранних версий в зачаточном состоянии. Какие-то анонимные функции, по-моему, в 4-й версии были – уровня create_function. Что-то такое.

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

Комплектация

Роутинг URL. Красивые URL необходимы сейчас, по-моему, всем. Давно уже никто не любит кучу GET-параметров в адресной строке. Все хотят видеть маленькие хорошие понятные URL. Красивые!

Обработчик запроса. Мы хотим брать GET, POST, cookies. Мы хотим видеть это все в объектах. Мы хотим работать с этим удобно.

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

Обработка ошибок нормальная хорошая – с exception. Преобразованы в exception все PHP нотисы.

Своя страница ошибок. Ошибка 404, 403.

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

Я дальше буду рассказывать о конкретных продуктах. Для этого доклада я сделал тест: взял фреймворк, которого никогда не видел. Это Fat-Free (я о нем буду говорить). Почитал документацию – простейшее приложение.

Блог был написан за 20 минут! Конечно, без наворотов, без капч, валидации серьезной, но основной функционал (список постов, добавить пост, добавить коммент) был написан за 20 минут. Я считаю, это очень хороший результат. Для прототипа это прекрасно, потому что прототип должен быть написан быстро, показан быстро. И уже реализовываться в полноценное конкретное приложение, которое будет работать дальше.

Расширение

Чем хороши микрофреймворки. Они расширяются сторонними компонентами. Причем фактически любыми сторонними компонентами. Хотите ORM, TPL Engine какой-то свой, сетевые коммуникации, подключить API для платежных систем, REST/SOAP, подключить свое кэширование (его самого куда-то встроить).

Это очень просто и наглядно. Это краеугольный камень таких систем: описывается в первых строках документации (tutorial, как правило). Именно за счет этого очень удобно.

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

Slim Framework

Все знают его – по-моему, он известный. В Google при запросе «PHP микрофреймворк» он вылезает первым. Хороший, удобный, быстрый. Подключается одним файлом. Сразу позволяет определить роутинг, контроллеры для запроса и вывести необходимую информацию на страницу.

Silex

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

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

Это не то чтобы фреймворк. Получилась очень удобная хорошая сборка. Сам Flourish – это библиотека, которая содержит в себе все необходимые (не знаю, как назвать) низкоуровневые, может быть, функции. Но она никак не может работать ни с запросами, ни с чем. Она обрабатывает ошибки, имеет драйверы для баз данных, базовые контроллеры (модель MVC).

Moor – это исключительно роутер. Хороший и удобный, быстрый роутер.

Это все вместе совмещается очень просто. Интегрируется друг в друга. Получается вот такая вещь.

Fat-Free

Собственно говоря, на нем я и писал блог. 55 килобайт кода, 2 файла, по-моему. Работает очень быстро. Очень понятен. Несмотря на довольно-таки фиговатую документацию, честно говоря, продукт весьма хорошо и удачен.

Собственно, все. Вопросы.

Вопросы и Ответы

Реплика из зала: Здравствуйте! Раз такой короткий доклад, тогда и вопрос короткий. Из чего состояло 20-тиминутное написание блога?

Андрей Синицын: В смысле «из чего»?

Реплика из зала: Какие процедуры вы выполнили, прежде чем блог заработал? Может быть, верстали что-то.

Андрей Синицын: Нет, никакой верстки, ничего. Просто написал несколько контроллеров для обработки задач, которые будет решать блог, и реализовал их на фреймворке. Получилось: список постов, конкретный пост и комментарии к нему. Такое приложение получилось написать за 20 минут.

Реплика из зала: Ничего не понятно!

Андрей Синицын: Почему? Может, пояснить? Что конкретно не понятно.

Реплика из зала: Не понятно, из чего, собственно, состоял этот процесс. Какой функционал включает в себя этот фреймворк? Мы же должны отобразить веб-страничку, правильно. Наверняка это все не из каких-то preset-ов создается, а делается на каком-то этапе вручную. Из чего состояли ручные операции, которые вы делали?

Андрей Синицын: Ручные операции – это написание конкретных контроллеров и моделей под конкретные задачи. Есть базовая модель и базовый контроллер, которые содержат в себе абстрактные методы (какие-то action абстрактные). Они переопределяются в дальнейшем коде и работают.

Мне нужно было добавить пост, мне нужно было отобразить его, добавить комментарий. Все это я писал руками. Url-ы, ошибки, база данных – все это было уже готово. За это у меня голова не болела.

Нормально, понятно объяснил?

Реплика из зала: Здравствуйте, Андрей!

Андрей Синицын: Добрый день.

Реплика из зала: Меня Максим зовут. Вы очень мало рассказали про расширения этого микрофреймворка до полноценного функционала.

Андрей Синицын: А что имеется ввиду под полноценным функционалом?

Реплика из зала: Смотрите, у нас микроядро, которое умеет всего лишь создавать url-ы, коннектиться к базе, парсить HTML. Мы хотим, к примеру, взять микрофреймворк Symfony и апгрейднуть его до всех возможностей Symfony. Или, скажем, будет выдержка из Django – микрофреймворк мы хотим апгрейднуть до Django. Это просто примеры.

Как микрофреймворк потом расширяется до полноценного функционала?

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

Если брать для примера Silex, мы берем что-то из Symfony, что там есть – конкретные вещи, которые нам нужны. Нам, например, могут быть не нужны сессии, нам может быть не нужна авторизация. Мы это не берем. Берем только то, что нужно. Есть механизм интеграции, который описан в документации.

Реплика из зала: Это я понимаю. Но ведь как всегда происходит в нашем мире: сейчас нужно одно, а через месяц – «давайте накрутим это, давайте накрутим это, давайте сделаем так».

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

Реплика из зала: Микрофреймворк нельзя считать началом чего-то большого?

Андрей Синицын: Можно, но нецелесообразно, мне кажется. Больше труда будет вложено, нежели изначально взять полноценное приложение.

Реплика из зала: Хорошо, спасибо.

Реплика из зала: Как в микрофреймворках работать с формами? Или они не поддерживают такие вещи.

Андрей Синицын: Как правило, да – это не заложено туда.

Реплика из зала: Только выводка? А как делать блог и как заполнять…

Андрей Синицын: Можно подключить сторонние валидаторы. Есть библиотеки для обработки форм – уже готовые, уже написанные. Их можно просто интегрировать туда, если они нужны. Фишка в том, что это конструктор: собирается только то, что нужно. Все остальное остается за кадром.

Реплика из зала: Понятно. Все остальные компоненты вы собираете сами?

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

Реплика из зала: Спасибо.

Андрей Синицын: Еще вопросы.

Реплика из зала: Здравствуйте!

Андрей Синицын: Добрый день.

Реплика из зала: Владимир Воронин. Вы говорили о том, чтобы быстро что-то показать клиенту. Существует куча готовых CMS так называемых. На них показать посты, страничку можно вообще за 10 минут.

Целесообразность применения именно… Я не говорю о высоконагруженных. Да, быстрота, действительно, а вот именно что-то быстрое показать. Все равно это дело переделывать потом: делать по-человечески, по-нормальному. Какую-то взять CMS или что-то еще.

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

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

Реплика из зала: Спасибо.

Андрей Синицын: CMS в данном случае не подойдут, потому что они предлагают какие-то куски. Не более того.

PHP-DI in Slim

Slim is a micro-framework for web applications and APIs. Given the framework is compatible with PSR-11, Slim can work with any container out of the box. Using PHP-DI with Slim is then easy.

However the PHP-DI bridge provides several additional features:

  • controllers as services, allowing dependency injection in controllers
  • intelligent parameter injections in controller

Setup

The latest version of the bridge is compatible with Slim v4.2 and up.

Once installed, instead of using the official Slim\Factory\AppFactory , instead use PHP-DI’s Bridge class to create your application:

If you want to configure PHP-DI, pass your configured container to the method:

Have a look at configuring PHP-DI for details on how to create and configure the container.

You can then use the application just like a classic Slim application, for example:

On top of that, extra features from PHP-DI are automatically available. Read the rest of the page to learn more.

Why use PHP-DI’s bridge?

Controllers as services

While your controllers can be simple closures, you can also write them as classes and have PHP-DI instantiate them only when they are called:

Dependencies can then be injected in your controller using autowiring, PHP-DI config files or even annotations.

Controller parameters

By default, Slim controllers have a strict signature: $request, $response, $args . The PHP-DI bridge offers a more flexible and developer friendly alternative.

Controller parameters can be any of these things:

  • the request or response (parameters must be named $request or $response )
  • route placeholders
  • request attributes
  • services (injected by type-hint)

You can mix all these types of parameters together too. They will be matched by priority in the order of the list above.

Request or response injection

You can inject the request or response in the controller parameters by name:

As you can see, the order of the parameters doesn’t matter. That allows to skip injecting the $request if it’s not needed for example.

Route placeholder injection

As you can see above, the route’s URL contains a name placeholder. By simply adding a parameter with the same name to the controller, PHP-DI will directly inject it.

Request attribute injection

As you can see above, a middleware sets a name attribute. By simply adding a parameter with the same name to the controller, PHP-DI will directly inject it.

Service injection

To inject services into your controllers, you can write them as classes. But if you want to write a micro-application using closures, you don’t have to give up dependency injection either.

You can inject services by type-hinting them:

Note: you can only inject services that you can type-hint and that PHP-DI can provide. Type-hint injection is simple, it simply injects the result of $container->get(/* the type-hinted class */) .

A question? Unsatisfied with the documentation? Please create an issue or chat on Gitter or Twitter.

PHP Slim Framework Создать контроллер

Я создаю API, используя платформу Slim. В настоящее время я использую один файл для создания маршрута и пропускаю его:

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

а затем передать функцию на маршрут

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

Поверните контроллер в функтор:

и затем выполните следующие действия:

PHP 5.6 Slim 2.6.2

«; > > $app = new \Slim\Slim(); $app->get(‘/’, ‘HelloController::index’); $app->run();

Обновление: PHP 5.6 Slim 3.0.0

«; > > $app = new \Slim\App(); $app->get(‘/hello/‘, ‘HelloController::hello’); $app->run();

Проблема с маршрутизацией на основе классов в Slim 3.0 – это доступ к $this / $app . Я думаю, вам нужно будет использовать global $app для доступа к нему.

В моем домашнем проекте я использую группы маршрутов с require_once . Что-то вроде

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

Быстрый маршрут Nikic – это очень минимальный маршрутизатор, поэтому некоторые из тонкостей больших фреймворков удалены. Вот базовое решение:

использование контроллера \ Psr \ Http \ Message \ ServerRequestInterface в качестве запроса; использовать \ Psr \ Http \ Message \ ResponseInterface как ответ;

Топ-пост этого месяца:  Сортировка данных по возрастанию и убыванию с помощью условия order by SQL
Добавить комментарий