Как стать автором
Обновить
3
Карма
0
Рейтинг

Пользователь

  • Подписчики
  • Подписки

Опрос. Какой php-фреймворк вы используете?

  1. Про крон команду с вами уже обсуждают в другом треде, не буду повторяться. Не считаю удобным дергать все ядро раз в минуту вне зависимости от того, должно что-то отрабатывать или нет. Есть консольные команды, которые можно запускать хоть руками, хоть кроном
  2. Сорян, замыленый глаз прочитал не так :) Есть подозрение, что готовых интеграций тоже хватает https://packagist.org/packages/oneup/flysystem-bundle. Про решение «изкоробки» уже обсуждали — зачем оно всем подряд? Например при работе с сервисной архитектурой все проекты подряд скорей всего не будут грузить файлы, а будет один сервис для этого

Опрос. Какой php-фреймворк вы используете?

form login хватает для классики. для внешней авторизации (хавоть чужую куку или апи какое хитрое авторизовать) этого уже мало, Guard принес много радости детишкам по поводу этого вопроса

Опрос. Какой php-фреймворк вы используете?

технически standard edition — это готовое boilerplate приложение на основе symfony fullstack (symfony\symfony) и доп. либ. официальное, православное. а сам фрейм отдельно, как вы указали

Опрос. Какой php-фреймворк вы используете?

  1. Нет, сфитмейлер умеет спулить емейлы. Либо откладывать до terminate ядра (т.е. шлет после отправки ответа пользователю, завершая коннект), либо можно спул обрабатывать внешним потоком (кроном, например). По умолчанию спул в памяти, отправка по терминейт
  2. Деплой должен настраивать такие штуки. Потому что это вещи, зависящие от окружения. В ином окружении (дев, тест) у нас такие вещи отключены или поставлены на более щадящие таймеры. В препрод, прод — работают. В проекте есть отдельный конфиг для whenever (так сложилось), который при деплое развертывается в готовый крон файл, этим же CI\CD отключается при откате релиза и прочее. А как вы отключаете ваши кроны при откате релиза?
  3. Filesystem — это часть пакета symfony/symfony (есть по вашей ссылки). symfony/symfony заменает filesystem. Можно установить отдельным пакетом
  4. FoS UB, если вы про него — это готовые пользователи, которые надо отметить, опять же не всем подходят. У нас на всех проектах авторизация внешняя, юзеры вообще в битриксе живут (так сложилось). Авторизация работает, в том числе встроенная симфонёвая. Есть проект с FoS UB (точней там Sonata Admin, которая тянет FoS UB
  5. Ок, не сталкивался, видимо
  6. Да, потому что технически это такая же внешняя библиотека, как доктрина. Поэтому она идет изкоробки в standard (как доктрина), но это не часть проекта symfony. Сути ссылки я не понял. Вижу что можно все подключить модулями.
  7. Не только в доктрине, есть knp pagination bundle, довольно удобная штука, умеет пагинировать не только доктрину, а много разных источников
  8. Возможно, сам пользуюсь доктриновским

Опрос. Какой php-фреймворк вы используете?

Большинство этих вещей устанавливаются в два клика пару команд — composer require и подключение в ядро. Ну и список такой себе сомнительный.

1 — спорно, это все таки решение конкретных задач по управлению потоком
2,3 — это не задача проекта, а задача CI\CD, системы сборки (capistrano, deployer, выбирайте по вкусу). В «большинстве проектов сложней бложика», если говорить вашими терминами, эти вещи уже управляются снаружи.
4 — Filesystem есть изкоробки, я не зря привел вам пример пакета, в котором есть ВСЕ пакеты симфони
5 — Есть нормальное с версии 2.8, до 2.8 тоже можно было использвать, но чуть сложней (больше кода писать). Сейчас (с 2.8) достаточно заимплементить один интерфейс.
6 — не очень понял, что это именно
7 — есть, свифтмейлер из коробки. Телеграм из коробки — а почему не ватсап? скайп? Почему фреймворк за вас выбирает канал? Опять же — куча готовых модулей. Выбираете свой и подключаете.
8 — готовый бандл
9 — готовый бандл, но иногда действительно рекомендуют alice

Если доставлять приходится во всех, то вы давно могли сделать свой метапакет, типа того же symfony/framework-standard-edition и переиспользовать его. Есть, кстати и rest-edition. А так вы видимо просто делаете что-то однотипное.

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

Опрос. Какой php-фреймворк вы используете?

Скорее наоборот. В Laravel из коробки на несколько порядков больше возможностей. В симфони же почти всё ставится руками, всегда, начиная с flysystem, заканчивая всякими monolog, swiftmailer и проч.


А вы точно пробовали пакет symfony/symfony и symfony/framework-standard-edition? Это как раз для тех, кто хочет готовый комбайн под новый проект, если что. Потом можно ненужные вещи (твиг, например, в АПИ не пригодился) — выпилить

https://packagist.org/packages/symfony/symfony
https://packagist.org/packages/symfony/framework-standard-edition

PHP-Дайджест № 102 – интересные новости, материалы и инструменты (1 – 12 февраля 2017)

С чего бы эвенты надо закидать камнями? Эвенты — это документированная точка расширения вашего приложения, вы как бы говорите разработчикам — «Э-гей, вот здесь вы можете изменить мир данные или отреагировать на них, вот вам событие, которое их инкапсулирует». Событие вполне себе может быть VO, если планируется только реакция на событие, или может быть мутирующим, если вы хотите чтобы расширения как-то дополнили или изменили ваши данные. Т.е. вы сами полностью управляет процессом реакции на события за счет паттернов.

Не знаю за ларавель, но в симфони евенты, как и все остальное, полностью DIC-based, это значит что можно найти все зарегистрированные листнеры (либо посмотреть в рантайме, если вы подписываетесь в рантайме).

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

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

Введение в проектирование сущностей, проблемы создания объектов

Мне кажется, вы пришли к конечным автоматам. Посмотрите на компонент workflow в symfony

Краткий обзор нововведений в Laravel 5.4

Там не в парсере дело, а в том, что при вызове консоли приложение регистрирует ВСЕ команды из ВСЕХ бандлов принудительно (и не лениво в данный момент). Если команд действительно много — это может стать проблемой. Но я до такого пока не доходил. В принципе всегда можно оформить PR с фиксом этой фичи, я например не вижу никакой принципиальной проблемы сделать их ленивыми сервисами или инициализировать лениво через замыкания

Краткий обзор нововведений в Laravel 5.4

Это такой себе аргумент. IDE уже давно все автокомплитит, причем с учетом типов.


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

PHP-Дайджест № 100 – интересные новости, материалы и инструменты (1 – 15 января 2017)

1а. Ну можно. Вы можете докинуть в метадата-фактори любой альяс + любую папку. Просто это не происходит автоматически.

http://symfony.com/doc/master/bundles/DoctrineBundle/configuration.html#configuration-overview вот простыня конфига, там строчка 309. В ней вы можете указать дополнительные мэппинги сверх того, что регается само. В том числе другие папки.

Переписывать вообще ничего не требуется. Требуется конфиг написать

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

1б. Если вы про передачу в контроллер через аргументы, то это есть, в виде парам конвертеров, аргумент-резолверов. Да и вообще вы можете пробросить любой аргумент руками в action через аттрибуты запроса.

Посмотрите, например, как реализован проброс UserInterface с версии 3.2

https://github.com/symfony/symfony/pull/18510

Регистрация сервисов под интерфейсами есть как автовайринг (вы можете просто объявлять зависимость от интерфейса, в него подтянется сервис, если он единственный имплементирует его, если нет, можно уточнить один раз)

А с версии 3.3 идентификатор сервиса будет опциональным
http://symfony.com/blog/new-in-symfony-3-3-optional-class-for-named-services

Идея регистрировать сервис сразу под всеми имплементируемыми интерфейами интересна, но 100% будут конфликты у всяких логгеров и других сервисов, которые генерятся фабриками

PHP-Дайджест № 100 – интересные новости, материалы и инструменты (1 – 15 января 2017)

1а) Можно. Потому что, внезапно, доктрина — это не симфони. Поэтому можно долить конфигурацию так, чтобы грузило несколько папок
1б) https://github.com/symfony/symfony/pull/15011#issuecomment-183884227 этого периодически действительно не хватает, но решение вроде как принципиальное на данный момент. Но есть сторонние имплементации https://github.com/mmoreram/symfony-bundle-dependencies

PHP-Дайджест № 100 – интересные новости, материалы и инструменты (1 – 15 января 2017)

1) Нет никаких жестких правил ). Жесткие правила нужны только в том случае, если вы хотите делать все автомагически (ну, типа quick-start). В остальных случаях вам достаточно имплементировать BundleInterface и зарегистрировать его в ядре. Аналогично с конфигами, расширениями и прочими конфигурациями.

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

2) В симфони тоже нет аннотаций, это формально внешняя библиотека (doctrine/annotations), хоть и рекомендуемая к использованию.

Ну в целом все ваши ответы сводятся к «как реализуете» (и это нормальная позиция), поэтому я считаю дальнейшие распросы бессмысленым, спасибо за информацию. Обычно действительно большая часть зависит от рук разработчика и авторов библиотек.

в Symfony 3.3 сделали ленивые листнеры, в том числе, посмотрите. Я думаю это решит многие из озвученных вами проблем (по флуду листнерами)

Еще раз спасибо за разъяснения

PHP-Дайджест № 100 – интересные новости, материалы и инструменты (1 – 15 января 2017)

Я примерно о том же. Ларка позволяет делать «более просто» за счет того, что некоторые решения фиксированы (ну по крайней мере, оно так выглядит, я могу ошибаться).

Я правильно понимаю, судя по вашему ответу, что запуск мидлвари, конфигурирующей другие милдвари (т.е читающая аннотации, каждый раз или проверяющая весь контейнер на предмет тегов), будет производиться на каждый запрос? В чем отличие от листнера, который будет проверять, нужно ли запускать другие миддлвари|листнеры|%tool% на каждый запрос?

Как эта мидлваря получит аннотацию конечного контроллера, если поверх него могут быть натянуты еще мидлвари?

Дефолты, если что, тоже можно повесить на группу роутов, если быть точным, то на импортируемый ресурс (yml, аннотации, что угодно). Еще есть options, которые можно устанавливаются и на импорты

PHP-Дайджест № 100 – интересные новости, материалы и инструменты (1 – 15 января 2017)

Нет, родной встроенный профилировщик symfony

Блэкфайр в прод режиме выдает по веб приложению вот такую картинку
blackfire.io


PHP-Дайджест № 100 – интересные новости, материалы и инструменты (1 – 15 января 2017)

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

То, что не все реализуют — это 100%, именно потому, что как я уже сказал, такая реализация (в ядре) привнесет очень много привязок к конкретным решениям. А симфони — оно про заменяемость компонент.

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

PHP-Дайджест № 100 – интересные новости, материалы и инструменты (1 – 15 января 2017)

В симфони тоже можно реализовать подобное. Технически, роутинг в симфони — это просто некоторая дыра, которая возвращает вам \callable по данным запроса (по pathinfo в самом простом случае). В пайплайне обработки запроса есть момент, когда этот \callable уже известен, и есть специальное событие, которое позволяет его обработать или подменить. Например, навешать те же миддлвари.

Технически, завязыватсья на роутинг в этот момент сложновато, т.к. в симфони нет «этих ваших» Route::get, роута как такового вообще может не существовать, как сущности (вспоминаем про дыру).

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

Т.е. если жестко приколотить себя к некоторым ограничениям, то можно сделать абсолютно идентичный механизм

А теперь встречный вопрос — насколько просто в Ларе будет установить те же мидлвари, скажем, считав аннотации у контроллера?

PHP-Дайджест № 100 – интересные новости, материалы и инструменты (1 – 15 января 2017)

А так, сейчас специально замерил два своих приложения — одно классика веб, второе апи, оба локально, dev режим, xdebug, sf 3.2, в каждом по 2-3 десятка бандлов, БД тоже локально в виртуалке (обычный рабочий комп)

Веб:


Апи:


Не вижу ваших сотен метров. То, что простая страничка сонаты отжирает сотню — это вопрос к самой сонате, которую лично я не долюбливаю. Симфони тут не причем.

PHP-Дайджест № 100 – интересные новости, материалы и инструменты (1 – 15 января 2017)

1) Симфони создает сервисы лениво. Более того, с ocramius/proxy-manager оно может даже создавать супер-ленивые сервисы (не инициализируются до использования, а не до инстанциирования зависимых). Приведенный бенч (опустим вопрос его предвзятости) показывает, что сбилженный конейтнер имеет свои бонусы по производительности.

2) Можете объяснить принципиальную разницу между мидлварью и листнером на пару событий kernel.request + kernel.response? Я думаю можно однозначно отобразить одно на другое, только вместо замыканий мидлвари отрабатывает EventDispatcher

3) Вот это выглядит странно в Ларе, если честно. Трендовая парадигма Симфони «Controller as a Service» выглядить более логично тут. У Лары это больше похоже на ФП.

4) Можно про тучу гвадров подробней? Если вы про секьюрити гварды, то их не туча, а в зависимости от сматченного фаервола. Если про другие гварды — то нужна конкретика. И, отдельно, чем «туча гвадров» лучше тучи миддлварей?

PHP-Дайджест № 100 – интересные новости, материалы и инструменты (1 – 15 января 2017)

А как же принцил Лисков?

Вы либо плохо читали RFC, либо подзабыли LSP. LSP разрешает расширение входных параметров и данный RFC как раз таки направлен на то, чтобы соответствовать LSP.

Т.е. если у вас есть класс-наследник с методом, расширяющим сигнатуру базового, то это не противоречит LSP, но в то же время позволяет оперировать терминами будущей совместимости (например вы можете расширить класс, чтобы они принимал не только array, но и \Traversable, и задеприкейтить старый для следующего мажороно релиза). В нынешней реализации это вызовет ошибку

Информация

В рейтинге
4,021-й
Зарегистрирован
Активность