Symfony 4.0 вийде в реліз наприкінці листопада 2017 року. Наступні кілька тижнів будуть опубліковуватися статті про нові ідеї і основні зміни в Symfony 4.
Symfony 3.0 був нудним і був більш лаконічною версією Symfony 2.8:
Symfony 3.0 = Symfony 2.8 — Deprecated Features.
Але що ж буде представляти з себе Symfony 4.0 у відмінності попередніх версій:
Symfony 4.0 = Symfony 3.4 - Deprecated Features + Нові концепції розробки додатків.
Або ось ще один варіант розвитку подій:
Symfony 4.0 = Symfony 3.0 + All features added in 3.x - Deprecated Features + Нові концепції розробки додатків.
Але найголовніше - Symfony 4.0 буде вимагати PHP 7. А тепер про нові концепції розробки.
У Symfony досить громіздкий процес установки зовнішніх бандлів:
На даний момент встановлення нового бандла одним композером часто не обходиться.
Як це зазвичай відбувається:
- Завантаження потрібних залежностей через composer require symfony/bundle
- Реєстрація бандла в app/AppKernel.php
- Реєстрація маршрутів, які надає наш новий бандл, якщо такі є
- Реєстрація необхідних налаштувань для бандла в app/config/config.yml
Перший крок автоматизувати не є можливим, хоча відчувається, що сам процес можна буде зробити більш зручним для кінцевого розробника.
Тепер подивимося на 3 і 4 етапи. Процес реєстрації конфігів для нових бандлів цілком реально автоматизувати, але швидше за все це буде виглядати як звичайна вставка стандартного набору налаштувань для бандла, при якому він може стабільно функціонувати, як це зроблено в Symfony Standart Edition для деяких встановлених пакетів.
Адже якщо ви погляньте на README будь-якого популярного бандла: всі вони починаються з одних і тих же танців з бубном - як сконфігурувати те, що ви тільки що встановили.
Видалення бандла в Symfony - це ще більший біль
Якщо вам потрібно вилучити сторонній симфоні бандл, який ви нещодавно встановили, то вам недостатньо буде зробити composer remove symfony/bundle. Пам'ятаєте, що нам потрібно виконати при установці нового бандла? Ну так от, тепер нам необхідно так само вручну видаляти все те, що ми тоді понаписали.
У Symfony Standart Edition теж не все так добре
Команда Symfony вже робила спробу надати розробникам певну відправну точку для початку розробки певних типів веб-додатків.
Найпопулярніший тип веб-додатків - це звичайні традиційні програми, які ми звикли бачити. Вони використовують базу даних, систему шаблонів, можливо вони навіть відправляють листи на пошту своїм користувачам.
Але що якщо ви хочете зробити API або Web Service? А може ви хочете власний Micro Framework Style?
Symfony Standart Edition звичайно ж надає якийсь вибір розробнику, але для швидкого старту і повної свободи все-таки нам буде або чогось не вистачати, або навпаки - отримаємо в підсумку занадто багато зайвих залежностей. Дистрибутиви для Symfony не масштабуються: немає можливості гнучко додати необхідні залежності в проект, які не були заздалегідь встановлені, але потрібні для повноцінного функціонування, як і немає можливості швидко позбутися непотрібних.
Інше питання з дистрибутивами - це те, що можливо ви не хочете зберігати у своєму проекті файли типу: LICENSE и README. Багато проектів не мають MIT ліцензії взагалі, як часто може не бути необхідності і в README.
Кілька років тому Symfony Standart Edition надали невелике демо для швидкого старту, але ми прибрали його після того як люди зустріли деякі труднощі при видаленні непотрібних речей у проекті. Це було і хорошим і поганим рішенням.
Ще не переконав? Подивіться на README REST дистрибутива:
Поняття дистрибутива не дуже підходить Symfony
І, напевно, тому дистрибутиви Symfony ніколи не злітали. Крім Standart Edition, жоден з них не користується популярністю, тому ми опубліковували тільки 3 з них:
Hello World Edition, Symfony CMF Standard Edition, Symfony REST Edition.
Самі дистрибутиви недостатньо гнучкі, вони не можуть розвиватися. Дистрибутиви є неправильною абстракцією. Нам не потрібен повністю завантажений проект, нам необхідна можливість розвивати і доповнювати наш додаток з плином часу.
Ідеальний варіант
Як розробник, я хочу почати з чогось малого, без безлічі залежностей, тим часом я хочу мати можливість удосконалювати свій додаток так, як вважаю за потрібне. Від Micro-Framework style до величезного моноліту і фреймворк не повинен тут заважати.
Починати новий проект з Symfony або допрацьовувати вже існуючий занадто складно для початківців і занадто громіздко для просунутих розробників. Ми можемо зробити краще.
Композицію спадкування
Більшість дистрибутивів представляють з себе форки Symfony Standart Edition з додатковими бандлами. А що щодо композиції? Що якщо я хочу використовувати дистрибутив API з Admin? Чи потрібні мені тут нові дистрибутиви? Можливо ні.
Symfony Flex - новий спосіб, який дозволяє створити і підтримувати вашу програму з легкістю. Це те, що спрощує створення додатків будь-яких типів, від найпростіших проектів в Micro-Framework Style, до проектів з величезною кількістю залежностей. Він автоматизує додавання та вилучення пакунків, дбає про те, щоб задати без вашої участі розумну конфігурацію для нового пакета та багато іншого.
Symfony Flex буде використовуватися типово для керування програмами на Symfony 4, проте він буде доступний як необов'язковий компонент для управління додатками на Symfony 3.3 і 3.4. Альфа версія Symfony Flex буде випущена перед виходом Symfony 4.
Залишайтеся з нами, наступний пост розповість вам більше про Symfony Flex. А поки оцінимо новий скелет програми з Symfony Flex. Не зовсім те, що ви очікували, вірно?
