Symfony *

Многие пользуются бандлом 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. А в этой части мы избавимся от некоторых неявных зависимостей, которые появляются из-за аннотаций.

Обычно считается, что контроллеры — наиболее связанные классы в приложении. Как правило, на основании данных запроса они получают или сохраняют данные в базу данных, затем превращают данные или результат сохранения в HTML, который выступает в качестве ответа клиенту, который произвел запрос.

Получается, что контроллеры — повсюду, они соединяют те части приложения, которые обычно достаточно независимы друг от друга. Это сильно повышает связанность контроллеров: среди их зависимостей есть менеджер сущностей Doctrine, шаблонизатор Twig, базовый контроллер из FrameworkBundle, и прочее.

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

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

Concrete CMS Inc. готовит к выпуску версию 5.7 своей системы управления контентом. Эта версия практически полностью переписана и архитектурно отличается от актуальной сейчас версии 5.6. В данный момент разработка версии 5.7 еще не закончена и доступна версия для разработчиков, о ней и поговорим.

[Дабы не возникло недопонимания, стоит пояснить, что автор оригинального текста — Fabien Potencier, создатель популярного PHP фреймворка Symfony — прим. пер.]

Совсем недавно, Nils Adermann, прислал мне милую открытку, в напоминание о нашей встречи три года назад на “SymfonyLive hackday” в Сан-Франциско. Nils присутствовал на конференции, т.к. за год до этого, он анонсировал, что phpBB в версии 4 перейдет на Symfony.

В то время, я серьезно интересовался темой менеджеров пакетов, ибо искал удобный способ управлять бандлами в Symfony2. Для плагинов в Symfony1 я использовал PEAR, но код был очень запутанным, ведь PEAR изначально создавался немного не для этого. Философия Бандлера из Ruby сообщества выглядела очень привлекательно, так что я начал поиски подобного пакетного менеджера. После долгих бессонных ночей, я наткнулся на libzypp, и моментально понял, что это оно! К сожалению libzypp — сложная библиотека, написанная на C, и в таком виде, совсем не подходила для Symfony.

Я смекнул, что хорошим менеджером пакетов, позволяющим пользователям легко устанавливать плагины/бандлы/моды наверняка интересуется и Nils, для phpBB, так что я завел об этом разговор на hackday в Сан-Франциско. Оказалось, что в то время, Нилс уже начал работу над Composer.

В этом посте я хотел бы поделиться не совсем обычным, для мира PHP, способе построения приложения, если угодно — архитектурой. Данный подход позволяет средствами PHP увеличить количество обрабатываемых запросов в разы. Так же я поделюсь своими наработками в этом направлении. Конечно данный подход не бесплатен, в плане требований к коду, но давайте всё по порядку.

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

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

Продолжение статьи выходит со значительной задержкой из-за моей лени, проблем со здоровьем и интернетом. За эти пару месяцев система доросла до версии 1.0.0, и все последующие правки в master-ветке зачем-то ломают работу системы, не будучи документированными. На случай, если кто захочет ставить систему руками, помните — опирайтесь на стабильные версии, помеченные тегами.

Самые нетерпеливые могут промотать вниз, скачать виртуальную машину с установленной системой (потребуется VirtualBox) и пощупать все самому, но для полноты опыта я бы рекомендовал сначала прочитать статью.

Итак. Что у нас по плану после хранения данных?

Недовно я познакомился с инструментом для создания виртуального окружения Vagrant, который я использую для веб разработки и очень рад этому. Но не все так радостно c реализизацией в этом окружении Symfony2 проекта. А именно, проблема в медленности загрузки (генерации) страницы! Итак возникла задача увеличить быстродействие, так как время загрузки страницы более 10-ти секунд ну вовсе не ахти.

У кого возникла такая же проблема, или кому просто интересно прошу под кат.

Как известно у Symfony 2 в Doctrine 2 из «коробки» нет поддержки некоторых стандартных функций Mysql, таких как UNIX_TIMESTAMP или ROUND и еще несколько других. В первую очередь статья для того чтобы понять как дополнять DQL своими функциями. Но перед написанием как следует «похабрить» и по «гитхабить», а вдруг уже кто-то написал, советую не городить велосипеды и воспользоваться уже готовыми наработками, например GitHub MysqlDoctrineFunctions.

Статья больше подходит для новичков.

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

Для решения текущих задач при программировании API интернет-магазина на Symfony2 решил подружить FOSUserBundle и WSSEAuthenticationBundle c алгоритмом sha512 и вскоре выяснил, что для этого потребуется небольшая доработка. Об этом и пойдет речь в моей статье.

Здравствуйте, Хабросообщество. В этой статье хочу рассказать, как можно подружить известный фреймворк Symfony2 и не менее известный трекер Jira.

Зачем связывать Jira и Symfony2?

В компании, где я работаю, возникла необходимость связать систему саппорта и трекер задач через API, чтобы заявки от клиентов могли быть легко преобразованы в тикеты. Первостепенной проблемой, которая встала на нашем пути, была интеграция аутентификации Jira (использовался механизм “Basic Authentication”) и системы безопасности Symfony2. Для понимания механизмов аутентификации и авторизации фреймворка необходимо ознакомиться с официальной документацией: http://symfony.com/doc/current/book/security.html.

Сегодня Фабиен Потенсьер сообщил, что SensioLabs смогла привлечь €5 млн (около $7 млн), которые будут потрачены на сервисы и консалтинг компании, а также на развитие Symfony и экосистемы фреймворка.

Фабиен замечает, что несмотря на наличие таких крупных игроков в мире PHP, как Automattic, Acquia и Zend, привлечение здесь инвестиций подобного размера — дело нечастое.

Что изменится для Symfony? Разработку Symfony Фабиен начал 7 лет назад, поставив своей целью улучшить уровень использования PHP в компаниях и создать фреймворк, реализующий часть лучших практик программирования. Поэтому лицензия останется прежней (MIT), и разработчики не намерены ее менять в будущем или создавать условно-бесплатную версию фреймворка — по их мнению, это попросту не имеет смысла. На полученные деньги планируется развивать экосистему, окружающую Symfony — бандлы (уже создано более 2200 бандлов) и приложения (CRM/CMS/e-commerce, сделанные на Symfony), а также улучшить средства разработки при помощи фреймворка.