Если речь об AppBundle - пока ещё нет, но будет

и что он у тебя админит?)

и что он у тебя админит?)

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

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

а все эти штуки типа документы, клиенты и т.д. они в админ бандле или в app bundle?

а зачем ты вручную ему отдаешь собранный запрос? он сам может подставить параметры

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

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

во- первых про кавычки тебе в чате подсказали

для c# свой суперсет c# реализовали что бы мутить DCI

Где вычитать об этом можно?

а все эти штуки типа документы, клиенты и т.д. они в админ бандле или в app bundle?

но кроме юзеров, всё в своих бандлов, т.е получается -AppBundle -User(сущность) -DocumentBundle -AdminBundle -PaymentsBundle

но кроме юзеров, всё в своих бандлов, т.е получается -AppBundle -User(сущность) -DocumentBundle -AdminBundle -PaymentsBundle

У тебя бандл админки за документы должен знать?

во- первых про кавычки тебе в чате подсказали

да конечно, всем спасибо, но это только часть моей пробелмы и мне ее нужно решить полностью

но кроме юзеров, всё в своих бандлов, т.е получается -AppBundle -User(сущность) -DocumentBundle -AdminBundle -PaymentsBundle

тебе не нужны бандлы тут. Вообще. Они никак тебе не помогают и ничего не дают. Это просто папки.

да конечно, всем спасибо, но это только часть моей пробелмы и мне ее нужно решить полностью

http://docs.guzzlephp.org/en/stable/request-options.html#query

для бандла разбирайся сам, как делать

У тебя бандл админки за документы должен знать?

да, админы с ними работают, а клиенты видят что с ними: приняты или комментарии к ним

но кроме юзеров, всё в своих бандлов, т.е получается -AppBundle -User(сущность) -DocumentBundle -AdminBundle -PaymentsBundle

Раньше сам тоже писал такие бандлы... Бандлы нужны только тогда, когда она может быть использована в других приложениях. Но по сути все мы пишем монолиты, а разделять их в бандлы не дает никакого профита. все равно все будет взаимосвязано

для бандла разбирайся сам, как делать

спасибо

тебе не нужны бандлы тут. Вообще. Они никак тебе не помогают и ничего не дают. Это просто папки.

А как без него? по факту получается - это отдельный объект, и пользователь и менеджер видит всё по разному. А данные одни что то запутался с ними)

А как без него? по факту получается - это отдельный объект, и пользователь и менеджер видит всё по разному. А данные одни что то запутался с ними)

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

А как без него? по факту получается - это отдельный объект, и пользователь и менеджер видит всё по разному. А данные одни что то запутался с ними)

Вы контроллеры можете создавать внутри вложенных папок. Например: Controller: Admin: Manager:

Вы контроллеры можете создавать внутри вложенных папок. Например: Controller: Admin: Manager:

или Admin Controllers Manager Controllers

но вообще модули Admin и Manager скорее всего совсем не то

А как без него? по факту получается - это отдельный объект, и пользователь и менеджер видит всё по разному. А данные одни что то запутался с ними)

так же с формами, сервисами, entity и т.д.

Вы контроллеры можете создавать внутри вложенных папок. Например: Controller: Admin: Manager:

и от туда сущность использовать Хм... логично)

ну то есть основное же у нас документы и клиенты, а все остальное - это что разные роли могут с ними делать

и нет смысла (но это не точно) выносить отдельно модуль для админов и отдельно для менеджеров

но вообще модули Admin и Manager скорее всего совсем не то

да, я привел не тот пример... вместо Manager - должно быть Client например

Т.е. в итоге разные контроллеры на одну сущность

Т.е. в итоге разные контроллеры на одну сущность

не обязательно,

можно почитать про "что такое cohesion" но это сложна по началу особенно

ну и опять же контроллеры и сущности - между ними было бы неплохо что-то типа service layer поместить

ну и еще - по поводу прав доступа - изучай security voters

и не делай проверок в контроллерах. Делигируй

ну и еще - по поводу прав доступа - изучай security voters

FosuserBundle - может помочь?

Т.е. в итоге разные контроллеры на одну сущность

Можно обойтись одним контроллером

FosuserBundle - может помочь?

с чем именно?

Можно обойтись одним контроллером

а не сложноват он будет? и в чем тогда разделение? там довольно сильный роутинг

с чем именно?

с разделением ролей и правами

FosuserBundle - может помочь?

fos user - гавно =))

fos user - гавно =))

а что тогда лучше?)

а что тогда лучше?)

я тебе уже сказал - symfony/security - voters

с ними разберись и будешь богом прав

тебе больше по сути ничего не нужно

я тебе уже сказал - symfony/security - voters

ага, спасибо, ща буду юзать

а не сложноват он будет? и в чем тогда разделение? там довольно сильный роутинг

разделение ответственности работает по другому

это про то что бы ты логику в контроллеры не ложил, а не про то что бы контроллеры как-то разделять по роутам.

а не сложноват он будет? и в чем тогда разделение? там довольно сильный роутинг

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

опять же что бы все было проще тебе придется ознакомиться с базовыми концепциями "хороших модулей" - cohesion и coupling

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

ну я думал да)

настройте всю логику по правам в security voters. потом в шаблоне будете показывать/скрывать разные блоки уже по правам

Спасибо парни, внесли ясноть, хотя местами ещё больше запутался Но вроде понял что менять и что учить

где именно запутались?

где именно запутались?

В разделение, думаю теперь что надо бандл Документы убрать, перенести сущность в AppBundle Но в AdminBundle своя же тема, он же должен сохраняться как бандл? И если да, то там же свой контроллер а вы вроде говорите, что надо использовать один

В разделение, думаю теперь что надо бандл Документы убрать, перенести сущность в AppBundle Но в AdminBundle своя же тема, он же должен сохраняться как бандл? И если да, то там же свой контроллер а вы вроде говорите, что надо использовать один

Я не говорю, что "надо" использовать один контроллер. Если у вас логика требует несколько контроллеров, пожалуйста

В разделение, думаю теперь что надо бандл Документы убрать, перенести сущность в AppBundle Но в AdminBundle своя же тема, он же должен сохраняться как бандл? И если да, то там же свой контроллер а вы вроде говорите, что надо использовать один

Вы можете оставить только один бандл "AppBundle". всю логику по админке делать внутри подпапок

Например: AppBundle Controller Admin DocumentController ClientController PaymentController Client DocumentController PaymentController

Например: AppBundle Controller Admin DocumentController ClientController PaymentController Client DocumentController PaymentController

?

а лучше просто src/Controller

Например: AppBundle Controller Admin DocumentController ClientController PaymentController Client DocumentController PaymentController

А вот так намного больше прояснилсь) пошёл приводить в порядок код Огромнейшее спасибо ?

Например: AppBundle Controller Admin DocumentController ClientController PaymentController Client DocumentController PaymentController

Так же и с формами: AppBundle Form Admin Document DocumentEditForm Payment PaymentEditForm Client Document DocumentCreateForm Payment PaymentCreateForm Security LoginForm RegisterForm

Так же и с формами: AppBundle Form Admin Document DocumentEditForm Payment PaymentEditForm Client Document DocumentCreateForm Payment PaymentCreateForm Security LoginForm RegisterForm

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

Например, DocumentSearchForm или DocumentFilterForm

и не делай проверок в контроллерах. Делигируй

а где корректно дергать?

а где корректно дергать?

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

а, ну так да, воутеры наше все

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

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

is_granted('ROLE_DOCUMENT_EDIT', $document)

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

Так же и с формами: AppBundle Form Admin Document DocumentEditForm Payment PaymentEditForm Client Document DocumentCreateForm Payment PaymentCreateForm Security LoginForm RegisterForm

https://gist.github.com/fesor/76d39b19b18f7103a7c058301dc6a8fe

ERROR: S client not available

https://gist.github.com/fesor/76d39b19b18f7103a7c058301dc6a8fe

?

is_granted('ROLE_DOCUMENT_EDIT', $document)

а где проверку делать?

а где проверку делать?

в security voter

is_granted('ROLE_DOCUMENT_EDIT', $document)

а зачем ROLE_? просто EDIT

ну и еще лучше что бы это небыло строкой

https://gist.github.com/fesor/76d39b19b18f7103a7c058301dc6a8fe

GOODNIES!

ну и еще лучше что бы это небыло строкой

конфигом?

ну и еще лучше что бы это небыло строкой

константой

а зачем ROLE_? просто EDIT

да, можно оставить и так, если роли простые. Но в моих документооборотах разделение ролей было чуть посложнее. Например есть Сотрудник, Департамент, Должность, и их связь. Роли даются для должностей. Например, CONTRACT_EDIT, PAYMENT_CREATE

константой

осталось решить, где их держать)

да, можно оставить и так, если роли простые. Но в моих документооборотах разделение ролей было чуть посложнее. Например есть Сотрудник, Департамент, Должность, и их связь. Роли даются для должностей. Например, CONTRACT_EDIT, PAYMENT_CREATE

прикол в том что мы там не роли проверяем а действия.

осталось решить, где их держать)

например в классе AppConst

is_granted(DocumentPermission::EDIT, $document)

например в классе AppConst

слегка пованивает, не находишь?)

@Skornkir ?

слегка пованивает, не находишь?)

конечно

is_granted(DocumentPermission::EDIT, $document)

?

пока у меня мысль только про хранение действий в сущности

@Skornkir ?

?

типа сущность знает, какие действия могут над ней совершаться

пока у меня мысль только про хранение действий в сущности

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

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

мне тоже не нравится

это слегка нарушение srp

так как сущности по сути не нужно это знать и её стейт и поведение не зависят от этих констант

при нормальном разделении на "модули" можно держать по классу с константами на модуль но это только если модуль реально маленький

так же и с названиями event-ов

updated, created, edited, removed и т.д.

updated, created, edited, removed и т.д.

EmailWasChanged

ProductHasBeenDelivered

DocumentWasSigned

так же и с названиями event-ов

и можно класть в класс ивента)

или вообще по имени класса слать