Symfony *

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

Как грибы растут стандарты, фреймворки, развивается и становится всё слаще синтаксис, растут разнообразные инструменты.

И это здорово!

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



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

Тест, разумеется, пятничный и шуточный. Но в нём всё-таки есть доля истины.

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

Менеджер зависимостей

В каждом проекте Symfony есть свои зависимости (бандлы). В версии 2.0 зависимости указывались в файле deps и подтягивались командой:

 php bin/vendors install

Сейчас для этих целей актуально использовать Composer.

Скачиваем Composer в корень репозитория:

Так вышло, что всю свою недолгую карьеру я занимаюсь разработкой API для мобильных приложений и сайтов на Symfony2. Каждый раз открываю для себя все новые знания, которые кому-то покажутся очевидными, а кому-то помогут сэкономить не мало времени. Об этих знаниях и пойдет речь.

Всем привет.

Каждый, кто программирует на Symfony 2, сталкивался с ситуацией, когда надо переопределить какой-то файл стороннего бандла. Будь то Twig-шаблон, контроллер или файл с переводом.

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

Собственно, с целью автоматизации данной операции родился плагин для Sublime Text 3, которым я хочу поделиться с Symfony2-разработчиками.

Среди php-разработчиков последнее время все сильнее набирает популярность Symfony2. Этот фреймворк позволяет использовать любые модули (в симфони они называются бандлы) для создания базовых фич проекта. По сути стандартная поставка симфони и является набором модулей. Но что если у вас несколько проектов, и вам необходим одинаковый набор функций на них, но подходящего модуля среди открытых нет? Не беда, можно написать свой.

Речь пойдет о бандле для Symfony2, первую версию которого я написал более двух лет назад. Всё это время я и мои коллеги активно его использовали, бандл периодически улучшался. Решил поделиться им с сообществом.

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

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

Это может быть обычный бандл, находящийся в папке src, и тогда при необходимости использовать его в новом проекте нужно скопировать его в новый проект. Но в таком случае возникает проблема с обновлением кода, ведь, когда код доступен для изменения, то он будет изменён (особые извращенцы изменяют даже код в папке vendor). Для удобства процедуры использования своего кода в других проектах можно оформить бандл как внешний, вендорный бандл, и управлять им через composer наравне с остальными сторонними бандлами.

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

Содержание:

1. Создание нового бандла
2. Добавление настроек в бандл
3. Подготовка бандла к публикации
4. Публикация бандла

Будет рассмотрено создание бандла для управления статичными страницами сайта. Можно найти несколько готовых подобных бандлов, но они либо слишком простые, либо слишком сложные (типа SonataPageBundle). Уровень статьи — продвинутый новичок. Подразумевается, что читатель уже умеет создавать бандлы в проекте, а также пользоваться контроллерами и шаблонами.

Генераторы кода упрощают жизнь рядового разработчика, во всяком случае призваны это делать, избавляя его от скучного написания однотипного кода. Один из таких генераторов команда Sylius'a представила как подарок для коммьюнити к Рождеству.

Ранее уже была публикация, которая демонстрировала как использовать Symfony2 и RequireJS с помощью бандла HearsayRequireJSBundle. Способ имеет место быть, знаю из первого ряда, потому как принимал непосредственное участие в разработке второй версии этого бандла. Тем не менее, этот бандл не использую. Клиентскую часть чаще разрабатываю как SPA и нашел более простой способ, о нем и пойдет речь.

Несколько дней назад состоялся релиз Symfony 2.6.0, который содержит множество интересных нововведений. Одним из наиболее важных является компонент VarDumper.

VarDumper призван заменить всем известную функцию var_dump() более современной и функциональной альтернативой — функцией dump().

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

Мажорные версии

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

Страх перед мажорными версиями растет своими корнями из нашего прошлого: вспомните Perl 6 или PHP 6. В мире Symfony вторая версия тоже была революционной по сравнению с symfony 1. Я понимаю, почему люди нервничают, когда слышат о третьей версии, и именно в этом посте я расскажу, почему вам не нужно паниковать.

Многие уже поставили обновление tzdata на свои любимые дистрибутивы и с нетерпением ждут конца света 26 октября 2014 года, когда можно будет в 2 часа ночи ощутить себя на все 3.

Но всё ли в порядке, если вы пишите на PHP и используете Symfony Forms, или просто php-intl?!
Мой ответ — нет.

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

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

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

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

Привет хабр!

На днях состоялся релиз молодой open source платформы Oro Platform (BAP). К сожалению, данное событие не было высветлено в русскоговорящей части интернета, поэтому хотел бы с вашего позволения восполнить данное упущение.
Эта статья имеет обзорный характер, так как является вступлением в цикл публикаций о платформе. Кому интересно, что же это такое – добро пожаловать под кат.

Доброго времени суток, %habrauser%!

Недавно встала задача, хранить в базе данные GPS с дальнейшей возможностью применения различных геометрических функций mysql. Управление координатами должно осуществляться из sonata-admin. Что из этого получилось можно прочитать под катом.

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

Используйте по меньше аннотаций

Лично я люблю аннотации, но с опытом понял, что они приносят некий дискомфорт. Дело в том, что всю конфигурацию перенести в аннотации нельзя. Остается 2 варианта:

• Максимум в файлах конфигурации ( например yml);
• Немножко в файлы, немножко в аннотации.

Если выбрать второй вариант, то при росте проекта получается каша. И в вашем коде аннотаций больше, чем логики. Отговорки по типу «так легче находить роуты» не принимаются. Так как если расскидывать файлы конфигураций правильно, ты всегда знаешь, где находятся роуты к определённым контроллерам. Я уже молчу про команды в консоли, по типу route:debug, и отладчик, в котором видно название екшена и имя роута.

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

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

Под катом я выписал основные тезисы, большинство из них подробно аргументируется внутри книги, в некоторых «шокирующих» местах помимо тезиса есть небольшое объяснение.

Использование Symfony2 и AngularJs в связке является хорошей идеей, но есть одна проблема — решение из коробки обладает проблемой в коммуникации. В этом посте будет рассказано о том, как автоматически декодировать JSON-запросы и использовать полученные данные при помощи Request Symfony используя библиотеку symfony-json-request-transformer (на самом деле всего-то один класс).