Статья является обзорной и не несет в себе никаких how-to-туториалов. Если вы случайно "напоролись" на неё в сети, то предупреждаю сразу, что она не научит вас использовать Zend Framework 3 (далее ZF3).
Привет, читатель! Решил я анонсировать свое детище на замечательном ресурсе Хабрахабр. Я не являюсь постоянным читателем, но понимаю, что основная часть людей ищущих что-то интересное натыкается непременно сюда. Пришел сюда спецом за трафиком, ибо нет сил наблюдать больше смерть своих творений.
Введение
Взглянув очередной раз на свой профиль GitHub я осознал, что все мои труды пропадают. Пропадают по причине того, что об этих репозиториях никто не знает. Из-за этого очень хорошие, на мой взгляд, репозитории "умирают". Какие-то я стараюсь поддерживать, но большая часть из них все равно медленно и мучительно тонет в глубине полного незнания. Тоже самое происходит и с zf-app-blank. Об этом проекте хоть и знает какая-то часть людей, но используется ли он — мне не известно. Сейчас многие просто напросто не видят никакого смысла что-то писать используя ZF3. И я решил это изменить, т. к. это очень хороший фреймворк и он незаслуженно остается в тени или используется исключительно гиками.
Идеей создания zf-app-blank послужила любовь к фреймворку и зависть к другим фреймворкам у которых есть какие-то готовые решения для того, чтобы «начать разработку еще вчера». У Zend Framework 3 такого совершенно нет. Есть ZendSkeletonApplication над которым нужно изрядно попотеть, чтобы выдать что-то стоящее, ибо сам ZF позиционирует себя, как "сделай сам", т.е. каждый разработчик волен делать так, как ему нужно. И это замечательно, на самом деле. Этим он мне и нравится.
Что внутри
Я запихал внутрь только самые необходимые пакеты, по моему мнению, для того, чтобы начать работу. Здесь не все запланированные, но большая часть из них. А также подружил это все между собой.
На момент написания статьи zf-app-blank версии 1.6.2 и имеет на "борту" следующее:
- PHP 7.1 — это минимальная версия. Что насчет 7.2 — неясно, т. к. нужны тесты, но есть предположение на этот счет: еще рано для переезда;
- Zend Framework 3 — Сам фреймворк;
- Twitter Bootstrap 4 — HTML, JS и CSS библиотека;
- Doctrine ORM 2 — ORM для работы с базой данных;
- Debug Bar — отладочная панель;
- Twig — шаблонизатор;
- Assetic Management — менеджер CSS, JS и прочих ресурсов;
- RBAC — управление доступом;
- Form — формы;
- Поддержка Vagrant — виртуальная рабочая среда;
- Поддержка Composer — пакетный менеджер для PHP;
- Поддержка Yarn — пакетный менеджер для JS;
- PostgreSQL как БД — база данных;
- MySQL как БД — база данных;
- YUI Comressor — компрессор для CSS;
- UglifyJS2 — компрессор для JS;
- PHP Coding Standarts Fixer — чекер и фиксер PHP кода;
- XDebug — PHP-отладчить, настроенный для работы из web и cli;
- Mailgun — сервис для отправки Email;
- Мультиязычность (English и Русский);
- Простое демо:
- Вход
- Регистрация
- Выход
- Подтверждение Email адреса
- Восстановление пароля
- Список пользователей;
- Symfony CLI — CLI;
- Codeception — тестирование;
- Sass — Препроцессор для CSS.
О том, как это все взаимодействует я постараюсь когда-нибудь изложить в документации (которой нет).
К сожалению...
zf-app-blank не решает полноценно проблему с frontend, потому что:
- заготовка нацелена на PHP;
- решается проблема только связанная с ZF3;
- в мире frontend все развивается очень быстро;
- нет времени и желания это поддерживать;
- для 19 звезд на проекте это бессмысленно.
При достойном сообществе вокруг заготовки можно подумать о чем-то кроме PHP, но пока что все совсем не так.
zf-app-blank не имеет документации, поэтому совсем "зеленым" пользователя совершенно не ясно, как это использовать. На данный момент ей смогут воспользоваться только при острой необходимости и подкованные разработчики с опытом использования Zend Framework. И это печально, т.к. ничего сложного здесь нет, но без документации сразу и не скажешь.
Текущее подготовленное Vagrant окружение работает только на unix-подобных системах. Если вы обладатель Windows — быстро вы проект не развернете, как мне кажется. Можно развернуть используя свое окружение и добиться прохождения всех тестов на требования к окружению запуская php bin/requirements из проекта.
В заготовке очень много тонких моментов, например, jQuery используется только для отладочной панели. В остальном, это старый, добрый Javascript без чего либо оверхедного. Для JS части Twitter Bootstrap используется Bootstrap Native. Отладочную панель хорошо бы иметь без jQuery вообще, т.к. в 2018 наличие jQuery неоправдано и вызывает проблемы.
Я стараюсь поддерживать проект и не оставлять его без внимания. Помимо того, что реализовано и выложено, у меня еще много вещей, которые я не опубликовал. Например: классы для работы Intl, улучшенный i18n, полезные Twig extentions, рабочее окружение для Docker и т.д. К сожалению, я не могу бросить все силы на этот проект и довести его до ума.
Установка
Установка будет выполняется с использованием сконфигурированного Vagrant окружения. Для тех, у кого Windows — извините, пока данный способ не был протестирован и настроен под данную ОС. Напоминаю, что вы можете развернуть проект используя свое окружение и добиться прохождения всех тестов на требования к окружению запуская php bin/requirements из проекта.
На момент написания статьи у меня Vagrant версии 2.0.0. Если у вас ниже — рекомендую обновиться.
Чтобы узнать свою версию введите следующее:
$ vagrant --version
Vagrant 2.0.0Вся установка сводится к тому, что нужно просто следовать инструкции из README.md репозитория.
Установим Vagrant плагины:
$ vagrant plugin install vagrant-vbguest
$ vagrant plugin install vagrant-hostmanagerСклонируем репозиторий:
$ git clone https://github.com/bupy7/zf-app-blank.gitМодифицируем .gitignore в корне проекта:
Удалим следующие строки:
# delete before to create own project
/yarn.lock
/composer.lockЗапустим процесс установки окружения:
$ vagrant upПосле ввода этой команды нас попросят немного подправить файл workenv/config/vagrant-local.yml, а именно указать Github токен. Как получить токен можно узнать здесь.
Укажем наш токен:
github_token: 62dbd9a1ee8c89d9127aee31234b51e6И изменим часовой пояс сервера на московский:
server_time_zone: Europe/MoscowИли можете изменить его на свой.
Также, можно изменить базу данных на PostgreSQL, если Вы хотите (по умолчанию используется MySQL):
db_type: pgsqlЕсть и другие интересные настройки о которых я расскажу в следующий раз. =)
После этого еще раз введем:
$ vagrant upи процесс возобновится. Запасаемся терпением, ждем окончания и приглашение начать работу (см. изображение ниже):
Далеко не убегаем, т.к. потребуется ввести пароль пользователя из под которого вы запустили Vagrant.
Настройка подключения к БД для тех, кто выбрал базу PostgreSQL:
В файле /config/autoload/local.php нужно закомментировать 8, 15 и 19 строку. Раскомментировать 7, 14 и 18 строку. Т.е. должно быть примерно так:
use Doctrine\DBAL\Driver\PDOPgSql\Driver as PgSqlDriver;
//use Doctrine\DBAL\Driver\PDOMySql\Driver as MySqlDriver;
return [
'doctrine' => [
'connection' => [
'orm_default' => [
'driverClass' => PgSqlDriver::class,
// 'driverClass' => MySqlDriver::class,
'params' => [
'host' => '127.0.0.1',
'port' => 5432,
// 'port' => 3306,
'user' => 'zf_app_blank',
'password' => '1234',
'dbname' => 'zf_app_blank' . (APP_ENV_TEST ? '_test' : ''),
],
],
],
],
...Изменим язык интерфейса на русский:
По умолчанию используется английский язык.
В файл /config/autoload/local.php добавим:
'translator' => [
'locale' => 'ru',
],Изменим часовой пояс приложения на московский:
По умолчанию Europe/London.
В файл /config/autoload/local.php добавим:
'time_zone' => [
'time_zone' => 'Europe/Moscow',
],Создадим новый Postbin для получения Email сообщений:
В README.md еще просят зарегистрироваться в Mailgun и вставить ключ и домен в настройки, но на этапе разработки достаточно Postbin.
Перейдем по ссылке http://bin.mailgun.net/ и скопируем полученный URL в /config/autoload/local.php:
'mailgun' => [
'debug' => true, // оставим без изменения
'key' => 'key-example', // оставим без изменения
'endpoint' => 'ВСТАВИМ СЮДА НАШ URL',
],
'mail' => [
'domain' => 'example.mailgun.org', // оставим без изменения
],Если у вас уже есть Mailgun и желание прописать все настройки, то дополнительно отключите debug-режим, чтобы получать сообщения на почтовый ящик. Postbin тогда указывать не нужно:
'mailgun' => [
'debug' => false, // поменяем на false
'key' => 'ВАШ КЛЮЧ MAILGUN',
'endpoint' => 'http://bin.mailgun.net/not-create', // оставим без изменения
],
'mail' => [
'domain' => 'ВАШ ПОЧТОВЫЙ ДОМЕН MAILGUN',
],И наконец, создадим схему базы данных:
$ vagrant ssh -c 'php bin/console orm:schema-tool:create'Должно появится зеленое сообщение:
[OK] Database schema created successfully! Означающее успешность операции.
Готово! Теперь можно посетить наш сайт по адресу: http://zf-app-blank.local
Демо
В этой заготовке есть небольшое демо, которое демонстрирует некоторый базовый функционал. Предлагаю немного ознакомится с ним.
Зарегистрируем нового пользователя и подтвердим его Email.
Перейдем на страницу регистрации: http://zf-app-blank.local/signup
Введем имя пользователя, Email и пароль.
Если вы решили использовать Postbin, то Email можно ввести любой, который пройдет валидацию. Если нет, то реальный Email, куда бы могло придти письмо.
После нажатия на кнопку "Зарегистрироваться" мы увидем сообщение об успешном завершении операции.
И в Postbin (или на эл. почте) нас будет ждать сообщение, которое нам необходимо, чтобы подтвердить наш Email адрес.
В этом письме нас интересует то, что выделено красным или ссылка для тех, кто предпочел отправку на реальный Email. Это наш маршрут, который ведет на страницу с подтверждением Email. Выполним переход: http://zf-app-blank.local/confirm-email/example@example1.ru/29ha%5Ezzvs5b25gxwjv
После этого нам скажут, что мы успешно подтвердили Email. Осталось ввести логин и пароль.
Заключение
Это была мини-презентация заготовки web-приложения на ZF3. Для более подробной информацией посетите репозиторий проекта. В следующей статье (если эта не уплывет в минуса) расскажу, как создать простое CRUD приложение.
Любителям Zend Framework и его идеологии, или просто тем, кто хочет и готов чем-то помочь — буду рад любой активности в проекте.
P.S. Звездочки на проекте тоже активность.
Ссылки
UPD
- 12.01.2018 12:46 — Более ясно изложил проблему про подготовленное Vagrant окружение и Windows.
Комментарии (46)
GoodGod
12.01.2018 13:21А не подскажите чем сделан листинг пользователей (на скриншотах) — в Yii есть виджеты (GridView). Они за тебя сделают таблицу на Bootstrap, Ajax пагинацию, фильтры в заголовке таблицы, а в Zend Framework — как?
BuPy7 Автор
12.01.2018 13:26+1В Zend самому нужно решать эту проблему. Каждый решает её один раз и таскает из проекта в проект.
Конкретно решение на скриншоте можно посмотреть в репозитории в модуле User. Там Zend Paginator, Bupy7 Form, Doctrine, Twig.
railsfun
12.01.2018 13:29-1смотрю ава у тебя тут не хуже моей ) Вообще касаемо топика хочу сказать что опасения разработчиков yii2 или подобных (если они есть! Я только yii2 знаю с таким набором фронта из коробки) каркасов абсолютно беспочвенны. Да, это может быть поначалу страшно. «Ах, мне бутстрап таблицу не создали». Зато вы ее потом создадите и все будет путем. Это не страшно. Хотя конечно мощные RAD-компоненты списочные для yii2 заменить нечем, времени уйдет больше на их реализацию конечно. Но вот так вот.
BuPy7 Автор
12.01.2018 13:34Я лично только Yii/Yii2 знаю, который решает все первичные проблемы из коробки. ZF не из его рядов. Нужно напрягаться по первости. Моя цель сейчас минимально снять напряжение с разработчика, который решит сделать проект на ZF3. Посмотрим, что получится.
Klenov_s
12.01.2018 13:52Вы реально считаете, что нужно плодить весь зоопарк, чтобы сделать что-то работающее?
Zverienish
12.01.2018 22:02На нем оказывается что-то делают. Как мне кажется, те, кто давно на ПХП и уходить с него не собираются, уже давно имеют наработанные решения. А вся новая кровь в веб программировании в js начинают писать, плюс где-то Go, Python.
sydorenko-vd
12.01.2018 23:39для 19 звезд на проекте это бессмысленно.
Сделайте docker контейнер, сведите всю установку к
docker-compose up
и количество звезд увеличится.
alo-blo
Спасибо за статью. Zend Framework никогда не умрет, поскольку Laravel, Yii не предназаначенны для Enterprise ПО. Для маленьких проектов Zend не так уж хороший, но для больших и Enterprise проектах самый идеальный с точки зрениа скорости, обслужевание и масштабируемостьи.
fornit1917
Имеет ли Zend какие-либо преимущества по сравнению с Symfony для больших и Enterprise проектов? Просто кажется, что на этом поле как раз Symfony стал стандартом де-факто, а Zend как-то не виден и не слышен.
alo-blo
Явные преимущества Zend-а:
1. Service oriented architecture
2. Module management system
3. Event driven programing
По моему Zend и Symfony на одном уровне.
Fesor
Это не преимущества. Это просто названия. Поясните как именно zend лучше подходит для SOA (и что вы понимаете под этим, так, на всякий случай, ибо кто только что не имеет ввиду под этим термином), в чем отличие в плане модульности? И как лучше помогает мутить эвеншуал консистенси.
BuPy7 Автор
Zend Framework имеет преимущество в слабой связанности (low coupling). По сути, здесь только каркас и подход. Все остальное — набор библиотек.
Fesor
я не вижу преимуществ скажем перед symfony в этом плане. Там тоже все базируется на модульности и low coupling. Особенно если мы будем смотреть на symfony flex.
BuPy7 Автор
В топики по Yii приходят поклонники Laravel и задают вопросы, «в чем преимущество Yii перед Laravel»? Обратное тоже справедливо. И это просто не аргумент.
Я работал только с Symfony 2, поэтому, что сейчас там происходит мне сложно сказать. Какая-то информация и впечатления от использования у меня, конечно, сохранились. Я не впечатлился. Возможно, я не так его приготовил, зато, я считаю, что прекрасно приготовил Zend Framework. Мне намного комфортней работать с ним. Это выбор вкуса, а о вкусах не спорят. Особенно, если конечный результат от этого не зависит.
Fesor
когда мы начинаем обсуждать субъективные штуки, вроде впечатлений о подключении модулей и т.д. мы уже выходим из категории объективных преимуществ того или иного решения.
Более того, вы не ответили на вопрос — как именно то что вы описали (что по большому счету субъективно) дает преимущества в виде: SOA, управление зависимостями, event driven?
Как по мне — никаких преимуществ, только вопросы вкуса. Их я поднимать не хочу ибо это в целом не имеет смысла. И я так же не хочу поднимать вопрос "кто лучше", меня конкретно интересовала ваша точка зрения по вышеозвученному вопросу (в частности — я все еще хочу узнать в контексте SOA в чем преимущества, ведь по идее вообще разницы нет).
BuPy7 Автор
> Более того, вы не ответили на вопрос — как именно то что вы описали (что по большому счету субъективно) дает преимущества в виде: SOA, управление зависимостями, event driven?
По SOA Вы задавали вопрос не мне.
> в частности — я все еще хочу узнать в контексте SOA в чем преимущества, ведь по идее вообще разницы нет
Разница только в удобстве реализации для конкретной команды.
Fesor
Что исходит из опыта команды. Но никаких ограничений для этой команды эксплуатировать свои подходы ни Zend ни Symfony не налагает.
BuPy7 Автор
> мы уже выходим из категории объективных преимуществ того или иного решения
Объективное преимущество вытекающее из нашего диалога: ZF не нужен Flex.
Fesor
ZF нужен component installer. Если вы ответите что он не нужен — то symfony тоже не нужен flex.
BuPy7 Автор
Тоже нет. В моей заготовке его нет. Установка в 2 этапа, которые я уже Вам написал ниже. Ну, а с ним в один присест.
Fesor
В моей заготовке тоже нет flex (пока-что во всяком случае). По поводу установки в 2 этапа (я так понимаю речь идет о дефолтных настройках модуля).
возьмем к примеру DoctrineORMModule и DoctrineORMBundle. Опустим момент с установкой самих пакетов так как они идентичны. В случае с zend мы регистрируем модуль в
module.config.php, в случае с symfony мы регистрируем бандл в kernel.Далее, в силу того что у нас нет роутинга, дальнейшее различия возникают лишь при конфигурировании модулей. В случае с Zend, мы добавляем конфигурацию на уровне наших модулей, в случае с Symfony мы полагаемся на конфигурацию приложения.
То есть, роль модуля
Applicationв symfony играет Kernel. В связи с этим я вообще не вижу разницы во флоу установки модулей.Так же как у вас может быть более одного модуля, выполняющего роль сервиса в контексте SOA например, вы можете иметь несколько кернелов (и это более чем нормальная практика). Дальше symfony вообще никак не регламентирует модульность проекта, полная свобода действий. Бандлы обычно для реюзабельных частей используются, а не для структурирования приложения.
BuPy7 Автор
Понимаете, Вы сами указываете на что-то — я отвечаю. Вы выдали Flex сначала за преимущество в плане low coupling — я указал, что он завязан на Symfony и это специально сделано для него…
Все эти объяснения мне дают понять лишь одно (если доверится Вам, т.к. сам я еще не проверил), то Symfony в этой же области, что и Zend Framework.
В Symfony есть моменты, которые мне не нравится, поэтому, я и другие люди со схожими взглядами выбрали Zend Framework. Это дело предпочтения, подхода и ощущений.
Fesor
так же как component installer завязан на zend. На связанность приложения это никак не сказывается.
Я полностью согласен, более того, я считаю что здоровая конкуренция никому не помешает. Но меня больше интересуют преимущества о которых говорит alo-blo.
однако возможно он имел ввиду преимущества перед laravel/yii и тогда в целом все логично.
BuPy7 Автор
И какие плюсы он дает? Вы сейчас говорите как раз о завязках на фреймворке. В ZF есть Component Installer, хоть там и надо было всего добавить модуль в список (массив). В ZF не нужно было никогда (с версии 2.0):
В ZF просто добавляется название модуля в
config/module.config.php, например,ZfcTwig. На этом установка заканчивается. Естественно, нужно, чтобы этот модуль у вас был. Но это работа Composer и одна единственная команда.И удаление также в 2 этапа: убираем из
config/module.config.php. Удаляем через Composer.Fesor
это плагин для composer который автоматизирует озвученную вами рутину. Вы можете работать как с ним, так и без него. Никакой завязки.
BuPy7 Автор
Сам плагин нацелен конкретно Symfony или я неправ? В репозитории написано: `Composer plugin for Symfony`.
Он поможет как-то проекту написанному на Yii/Laravel/Zend?
Fesor
нет, но он невилирует описанные вами преимущества (в частности это по сути является тем же, что и zend component installer).
pbatanov
Вроде как не особо завязан, если создать экосистему рецептов для других фреймворков и переработать структуру шаблонного проекта на них так, чтобы туда можно было автоматически вставлять\удалять данные, то можно будет подключить и флекс.
Вся привязка к симфони там сейчас только в рецептах, которые по понятным причинам есть только для симфони и околосимфонёвых проектов.
Но, насколько я знаю, можно писать и подключать свои рецепты
Надо отметить, что «написанному» проекту флекс никак не поможет. Даже написанному на симфони. Он помогает быстро стартовать новые проекты
sydorenko-vd
По-моему он уже на пол пути к смерти. Symfony, особенно 3-4 версии значительно прибавил в развитии. Нету "реальных" причин выбирать Zend, когда есть Symfony.
railsfun
У вас всегда де-факто все и «на пути к смерти». Ну-ну. Давайте будем говорить прямо — есть разные каркасы, все они сводятся к выдаче юзеру веб-страниц. Вы не ракету Челомея лунную проектируете и не ракету Королева.
railsfun
ПыСы: касаемо же Symfony он мне тоже нравится. Хотя я вообще рельсист. Но почему сразу Зенд то «на пути к смерти»? Разработчики языка PHP, создавшие Зенд, об этом знают вообще, или это очередное диванное мненьице?
sitIgor
А как в Symfony c middleware'ми?
Есть ли что то похожее на Zend Expressive? Не так давно искал — не нашел ничего…
Чем тогда решают схожие задачи, подпиской на kernel.request?
пс. сорри если не в тему
railsfun
middleware, точнее их некое подобие, можно сделать примерно так. Но вообще если честно, глубоко в тему не вникал именно эту.
sydorenko-vd
Чистая статистика вакансий в три раза больше на symfony, на zend в основном поддержка zf1-2 веб-приложений. Да и личное впечатление не очень.
Я начал писать на Zend как раз из-за
и был расстроен излишней сложностью и неочевидностью процесса разработки
Лично мне кажется, что Laravel это и есть php мир, каким он должен быть. Быстрое создание прототипов и запуск. Конкурент Rails. Но никак ни Spring как в случае Zend и Symfony, а с выходом Spring Boot вообще смысл в Symfony теряется, и сейчас фреймворк идет по принципу упрощения, и если вы посмотрите Symfony 4, минимализм в чистом виде.
А на счет "на пути к смерти", вот опрос хабра, где на вопрос
"На каком фреймворке вы бы начали следующий проект?" Zend получил 1.8%, и это по вашему не смерть?
railsfun
Это мой последний ответ в нашей дискуссии, так как по личным и довольно для тебя нелестным причинам, продолжать дискуссию я не хочу (мое время дорого). Однако Laravel какой якобы «php мир» ты изучил отчасти благодаря мне — я бывший член команды перевода документации русскоязычного комьюнити.
И не удержусь от замечания — «опрос Хабра» это не заседание Госдепа США. Это ничего не значит. Судьбу Zend Framework решает не «Хабр» и его опросы.
Это все что мне есть сказать тебе на данный час )
sydorenko-vd
Чувак, не обольщайся, я читал официальную доку, и даже не знал о существовании переводов.
Как раз они и решают — люди. И чем меньше людей интересуются той или иной технологией тем скорее она умирает. Рейтинг stackoverflow, github или reddit еще более разгромен.
BuPy7 Автор
Здесь более высокий уровень вхождения и преследования SOLID принципов, а не KISS, и не Worse is better. Разные подходы.
Когда устанете от "херак-херак и в продакшн" — welcome. =)
Spring — это, Java. Symfony — это, PHP. На Java час разработки стоит дороже, чем аналогичный на PHP. Это разные ниши. Для разных проектов и клиентов.
Все-таки, он получил хоть что-то. А это уже не смерть. Он не получил 0.
Fesor
это разные штуки с разными авторами. zend framework имеет слабое отношение к zend engine.
alex6636
Угу, с точки зрения скорости...magento сильно быстрый?
Fesor
если сделать мегенту на чем угодно он будет медленным.
alex6636
ну если наследовать как в ZF по 10 классов друг от друга, то конечно
BuPy7 Автор
Там затык не в этом. В 2012 (работал только в этом году с ней) были причины из-за:
Все, что вспомнил. Наследование здесь не при чем.
Fesor
во первых подобного в ZF нет.
Да и наследование не налагает никаких накладных расходов на рантайм. Накладных расходов на вызов метода в этом случае будет такой же как просто вызов метода объекта (это ж не prototype-based наследование).