А еще он борщ умеет варить.
Никто не говорит что плагин плох, но вам предложили более простое, лаконичное и семантически более верное решение.
Все остальные требования как, то: колбэки, «стилизовать отца» (надо бы запомнить фразу) и т.д., могут понадобиться, а могут и нет. Если они нужны они решаются элементарно в пару строчек JS.
Вы в ответ на мой пример привели свой, уточнив, что в моём примере непонятно, что это за аккаунт.
Не понятно аккаунт от которого выставляется счет фактура, аккаунт которому, или может это вообще корреспондент через которого?
Именовать аргументы классом — это хорошая практика
Это только ваше имхо и не более. Специально открыл посмотрел Э. Эванса по этому поводу и что то не увидел такой практики при построении домена. На уровне приложения да, есть такое, но не в домене.
Смысл паттерна как, раз таки в том что программисту без разницы сколько валют в системе. Деньги это никогда не просто количество, это именно количество в определенной валюте. То что она в системе одна и используется по умолчанию никак этого не отменяет.
Это беда разгулявшейся фантазии.
Простите если жестко, но только вашей. Я привел абстрактный пример. Вы сделали из него выводы относительно вашей системы.
А вообще спорим мы не о том. Я в примере показал только то что именовать аргументы в соответствии с именами их классов, имхо, масло-масленное и дурной тон.
Плюс, не факт, что мы работаем именно с аккаунтом клиента, а не с любым аккаунтом.
Потому и принимаем по интерфейсу Account, но в контексте данного метода это не абстрактный аккаунт, а именно клиент, т.к. мы создаем какаю-то счет-фактуру.
В CI есть такая практика как Extremal Continnuous Deployment, когда каждый прошедший билд тут же идет на боевой сервер. Но естественно, следует понимать чем это может быть чревато. Кому интересно, могут почитать блог человека практикующего такой подход.
Примера не понял. Можно чуть подробней?
А про тесты, я обычно в config.yml для тестового окружения просто не помечаю сервисы тэгом security.secure_service. Подробнее можно почитать в документации. Хотя конечно все зависит от задач.
БЭМ — это интересная технология, но достаточно сложная в описании (при всей ее внутренней простоте). До сих помню первый вопрос из зала на Я.Субботнике в Минске после доклада по БЭМ: «Я так и не понял, так что такое БЭМ?»
Не могу представить ситуацию когда в Symfony Command понадобится isGranted, но вообще никто не мешает добавить опции --user и --pass и авторизовать пользователя.
Для модульных тестов просто делается мок, но если сервисы построены правильно обычно даже этого не требуется, т.к. вся аутентификация происходит уровнем выше: или в контроллере, или через Secure аннотацию сервиса.
Вы все поняли правильно. Меня смущает вот эта проверка: is_granted('[наименование привилегии]', [объект]), потому и предложил посмотреть в сторону ACL.
Если вам не нужна проверка на уровне объекта то почему бы не использовать просто массив ролей для пользователя, аля: [ROLE_CREATE_WORKORDER, ROLE_UPDATE_WORKORDER, ROLE_CREATE_TICKET, ROLE_DELETE_TICKET], или раз уж «Один пользователь имеет строго одну роль» то использовать группу к которой уже привязывать список ролей (у себя делаю именно так).
А по теме, спасибо! Программа может оказаться очень полезной в определенных ситуациях.
Никто не говорит что плагин плох, но вам предложили более простое, лаконичное и семантически более верное решение.
Все остальные требования как, то: колбэки, «стилизовать отца» (надо бы запомнить фразу) и т.д., могут понадобиться, а могут и нет. Если они нужны они решаются элементарно в пару строчек JS.
Прочитать по ссылке вы не удосужились видимо:
Счёт-фактура выставляется (направляется) продавцом (подрядчиком, исполнителем) покупателю (заказчику) после окончательного приема покупателем (заказчиком) товара или услуг. © Wikipedia.
А customer это как подсказывает Google Translate клиент, заказчик, покупатель.
Не понятно аккаунт от которого выставляется счет фактура, аккаунт которому, или может это вообще корреспондент через которого?
Это только ваше имхо и не более. Специально открыл посмотрел Э. Эванса по этому поводу и что то не увидел такой практики при построении домена. На уровне приложения да, есть такое, но не в домене.
Про это и речь. Все зависит от потребностей домена.
Счёт-фактура выставляется продавцом покупателю. Wiki.
Смысл паттерна как, раз таки в том что программисту без разницы сколько валют в системе. Деньги это никогда не просто количество, это именно количество в определенной валюте. То что она в системе одна и используется по умолчанию никак этого не отменяет.
Простите если жестко, но только вашей. Я привел абстрактный пример. Вы сделали из него выводы относительно вашей системы.
А вообще спорим мы не о том. Я в примере показал только то что именовать аргументы в соответствии с именами их классов, имхо, масло-масленное и дурной тон.
Не факт, зависит от потребностей домена.
Потому и принимаем по интерфейсу Account, но в контексте данного метода это не абстрактный аккаунт, а именно клиент, т.к. мы создаем какаю-то счет-фактуру.
martinfowler.com/eaaCatalog/money.html.
А про тесты, я обычно в config.yml для тестового окружения просто не помечаю сервисы тэгом security.secure_service. Подробнее можно почитать в документации. Хотя конечно все зависит от задач.
Для модульных тестов просто делается мок, но если сервисы построены правильно обычно даже этого не требуется, т.к. вся аутентификация происходит уровнем выше: или в контроллере, или через Secure аннотацию сервиса.
Если вам не нужна проверка на уровне объекта то почему бы не использовать просто массив ролей для пользователя, аля: [ROLE_CREATE_WORKORDER, ROLE_UPDATE_WORKORDER, ROLE_CREATE_TICKET, ROLE_DELETE_TICKET], или раз уж «Один пользователь имеет строго одну роль» то использовать группу к которой уже привязывать список ролей (у себя делаю именно так).