Symfony *

Ранее уже была публикация, которая демонстрировала как использовать 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 (на самом деле всего-то один класс).

Многие пользуются бандлом SonataAdminBundle при разработке на Symfony2. Этот бандл позволяет в кратчайшие сроки создать CRUD-админку для сущностей Doctrine и Mongo. В частности, позволяет быстро и легко сделать странички для добавления сущностей, в том числе включающими связи Один-ко-Многим и Многие-ко-Многим. Вот с последним пунктом у меня и возникли проблемы. В статье я покажу решение, как можно организовать установку тегов для нескольких сущностей, задействуя всего одну промежуточную таблицу, с помощью бандла FPNTagBundle, и что пришлось сделать, чтобы этот бандл заработал в SonataAdmin. А вначале рассмотрим, как реализовать редактирование сущностей (в том числе с тегами) на простой SonataAdmin

О пользе модульного подхода в программировании на любом языке говорилось уже достаточно много, по-этому приведу кратко основные положительные моменты для JS особо не вдаваясь в подробности. Разделение приложения на модули позволяет сделать код:

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

Так же документация модульного кода гораздо более эффективна.

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

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

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

В ряде Symfony-проектов у нас используется hstore. Для тех, кто не в курсе, hstore — это PostgreSQL-модуль, позволяющий сохранять массивы значений в одном поле. Мы накидали отдельны DBAL-тип hstore, а также тип поля hstore для Doctrine ORM, для прозрачного работы с такого рода полями.

Оформлено все в Symfony-бандл Intaro\HStoreBundle. Но речь в целом не о бандле. Речь о том, как мы попробовали оптимизировать его с помощью Zephir.

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

Как работает «отлов» исключений

Чтобы правильно пользоваться инструментом важно понимать, как он работает. Обработка исключений, в случае типового запроса через web, в общих чертах описана здесь. Там же упомянут весьма полезный HttpExceptionInterface, о котором напишу ниже.

В этом посте нет никаких откровений для тех, кто копался в коде symfony 2.х и её компонентов. Таким читателям можно смело пропускать этот пост.

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

Акцентирую ваше внимание именно на symfony2, поскольку буду использовать FOSElasticaBundle, который позволяет описывать mapping индексов elasticsearch в удобных yaml конфигах и привязывать к ним сущности Doctrine ORM или документы Doctrine ODM. Промаппленные индексы заполняются из связанных доктриновских сущностей с помощью одной единственной консольной команды. Кроме того, он включает в себя вендорную библиотеку для конструирования поисковых и фильтрационных запросов. Результаты поиска возвращаются в виде массива объектов сущности или документа Doctrine ORM/ODM, привязанной к поисковому индексу. Подробнее о FOSElasticaBundle, традиционно, на гитхабе: github.com/FriendsOfSymfony/FOSElasticaBundle

Использование бандла позволяет полностью абстрагироваться от манипуляций с чистым JSON, что-то кодировать и декодировать функциями json_encode и json_decode, лезть куда-то с помощью сurl. Здесь только ООП подход!

Немного о схеме данных в SQL

Поскольку мои товары хранятся в реляционной СУБД, мне понадобилось реализовать EAV модель для их свойств и значений (подробнее: en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%93value_model )

В результате, у меня вышла вот такая схема данных:

В процессе разработки интернет-магазина была поставлена задача реализовать адресную книгу для авторизованного пользователя. Таким образом, чтобы сам пользователь хранился в базе mysql, а связанные с ним адреса — в mongoDB. Отдельного внимания данная задача заслуживает в части управления пользователями и их адресными книгами из админки, основанной на SonataAdminBundle.

Исходные данные:

Есть доктриновская сущность User и доктриновский документ Address. Между ними должна быть установлена связь один-ко-многим. Всё это должно управляться с формы добавления пользователя в админке на базе сонаты. Поскольку у 1 юзера может быть много адресов, на форме добавления пользователей должна быть реализована коллекция форм добавления адресов с кнопками «добавить», «удалить» и inline редактированием полей связанных адресов. Этим мы и займёмся далее.

Что нам надо:

1) Установить @Gedmo\References doctrine-extension

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

Спасибо! И позвольте, я объяснюсь.

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

Шансы, что контроллеры придется переносить на другой фреймворк, близки к нулю. (Рафаэль Домс)

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