SQL запросы ты зачем приплел?

это не диалог. это игра в угадайку

повторяй как мантру - "разделение ответственности"

у тебя относительный путь УЖЕ есть

не надо ничего получать ни откуда

тебе надо просто ссылку сгенерить

учись операции разбивать на этапы и изолировать их друг от друга

странно, что еще никто не начал делать ставки, когда @fes0r устанет)

инача на проекте гда операции посложнее "достать из базы и отобразить" ты просто завязнешь

странно, что еще никто не начал делать ставки, когда @fes0r устанет)

он тут 24/7 пишит без остановки, я подозреваю что он бот )))

общаться на интересные темы это ок. а тут как с радио разговаривать

у тебя относительный путь УЖЕ есть

Тогда я не знаю) Ничего в голову не приходит кроме: C:\\etc

кто делал ставки - я устал

просто ссылку на картинку сгенерить не может

return chat.dev/.$filePath

вот она

вот она

ну так делай

Вопрос. Как быть если на stage сервере в prod env приходится грузить фикстуры для тестов? Сейчас к команде загрузки фикстур добавлено —env=test, так как бандл с фикстурами в prod env отсутствует. Эта история заставляет вармапить кеш ещё и для test env. Насколько фиговым будет решение перетащить загрузку бандла с фикстурами ещё и в prod env?

заведи stage env

+

Вопрос. Как быть если на stage сервере в prod env приходится грузить фикстуры для тестов? Сейчас к команде загрузки фикстур добавлено —env=test, так как бандл с фикстурами в prod env отсутствует. Эта история заставляет вармапить кеш ещё и для test env. Насколько фиговым будет решение перетащить загрузку бандла с фикстурами ещё и в prod env?

вчера такое же решал. временно можешь решить через parameters.yml, в нем указываешь путь к фикчерсам. но лучше завести staging

вчера такое же решал. временно можешь решить через parameters.yml, в нем указываешь путь к фикчерсам. но лучше завести staging

там бандл с фикстурами просто подключается только для dev и test. отдельный энв решает этот вопрос

ребят, в s4 , уже неправильно в src держать несколько бандлов? каждый должен быть как отдельный проект (рецепт)?

ребят, в s4 , уже неправильно в src держать несколько бандлов? каждый должен быть как отдельный проект (рецепт)?

а зачем тебе несколько бандлов? что в них?

p.s. рецепт это если ты хочешь бандл реюзать в другом проекте

а зачем тебе несколько бандлов? что в них?

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

и ты можешь их держать в одном репозитории если хочешь (и потом через split-tree дистрибьютить)

и ты можешь их держать в одном репозитории если хочешь (и потом через split-tree дистрибьютить)

это как?

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

вот есть у тебя проект, по какому принципу ты на бандлы делишь?

есть ли CoreBundle/CommonBundle/MainBundle?

там чисто инфраструктура или бизнес логика тоже выносится по бандлам?

вот есть у тебя проект, по какому принципу ты на бандлы делишь?

ну к примеру у меня допустим есть своя реализация (LdapBundle), есть основа AppBundle ....

ну если ты не собираешься ее юзать в другом проекте - накой тебе выносить это и делать рецепт?)

ну если ты не собираешься ее юзать в другом проекте - накой тебе выносить это и делать рецепт?)

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

псссст

неймспейсы

ну в общем суть вопроса был правильно ли держать в сурсах бандлы другие (в с4), значит нет

в с4 нет бандлов)

вру

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

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

получается, если мне нужны будут 50 сущностей, в папке Entity будут 50 файлов

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

src/User/Entity src/Shop/Entity

и так далее

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

а, я как то про это не подумал.

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

но если бы я писал на s4 - попробовал бы так в первую очередь

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

скорее всего генераторы будут криво работать

сущностей и прочего?

думаю, зависит от настроек

сущностей и прочего?

да

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

src/User/Entity src/Shop/Entity

а разве не /src/Entity/{User,Shop,Etc}?

вы можете сами сконфигурировать пути к маппингам. Там уже без разницы, где они

это уже по вкусу в такой ситуации будет и src/Controller/{User, Shop ... }, если запариваться с разделением

а разве не /src/Entity/{User,Shop,Etc}?

в shop, user могут быть не только entity ;)

вотвот

в shop, user могут быть не только entity ;)

тогда это модульная структура, надо конфигурить

/src/domain/myContext/user ;)

тогда это модульная структура, надо конфигурить

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

бл.

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

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

Вопрос: Как вы определяете где стоит дефайнить сервисы? Есть два места: app/config/services.yml и AppBundle. Сейчас я разделяю по принципу все что работает без бандла - в app

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

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

я все таки полагаю, что модуль это независимая единица

app для конфигурации, описание сервисов это конфигурация...

ERROR: S client not available

в общем в отдельной папке с отдельным неймспейсом работает . но генератор генерит в базовую папку

в общем в отдельной папке с отдельным неймспейсом работает . но генератор генерит в базовую папку

там можно неймспайс указать

в общем в отдельной папке с отдельным неймспейсом работает . но генератор генерит в базовую папку

наверняка опция есть

я все таки полагаю, что модуль это независимая единица

смотря что считать "зависимостью"

смотря что считать "зависимостью"

ну если я создал /app/User/entiry /app/User/contoller то это нифига не модуль, просто смысловое разделение. Для удобства навигации

ну если я создал /app/User/entiry /app/User/contoller то это нифига не модуль, просто смысловое разделение. Для удобства навигации

нет, это монолит который пора бить на модули :)

там можно неймспайс указать

чет не помогает. либо я что то не так делаю

нет, это монолит который пора бить на модули :)

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

чет не помогает. либо я что то не так делаю

а что ты делаешь, покажи ? :)

а что ты делаешь, покажи ? :)

ну я пытался скормить make:controller Test\NewController также make:controlelr Test:NewController

ну я пытался скормить make:controller Test\NewController также make:controlelr Test:NewController

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

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

нет

app для конфигурации, описание сервисов это конфигурация...

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

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

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

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

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

правильно я понял?

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

поддерживать может и проще, но вот заставить их работать вместе очень сложно

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

у меня модули зависят от интерфейсов :) С помощью них и общаемся, это позволят подменять модули друг для друга.

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

а ты уверен, что в 4ке так можно? или абстрагируешь от 3ки?

а ты уверен, что в 4ке так можно? или абстрагируешь от 3ки?

причем тут фреймворк? ты задал папку для нового namespace? в симфони корневая для ее namespace потомему scr

причем тут фреймворк? ты задал папку для нового namespace? в симфони корневая для ее namespace потомему scr

"autoload": { "psr-4": { "App\\": "src/", "App\\Test": "src/Test" }

у меня модули зависят от интерфейсов :) С помощью них и общаемся, это позволят подменять модули друг для друга.

один хрен монолит. потому что у тебя один модуль без другого не может работать

"autoload": { "psr-4": { "App\\": "src/", "App\\Test": "src/Test" }

так не надо

если только вне папки scr

получается, если мне нужны будут 50 сущностей, в папке Entity будут 50 файлов

или ты прекратишь ложить сущности только в одну папку

тогда прописывай

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

сторонние бандлы должны быть в вендоре ;)

"autoload": { "psr-4": { "App\\": "src/", "App\\Test": "src/Test" }

т.е. "autoload": { "psr-4": { "App\\": "src/", "Test\\": "test/" }

т.е. "autoload": { "psr-4": { "App\\": "src/", "Test\\": "test/" }

а я делаю Tests\App\: test/

хз... как лучше

а лучше наверно App\\: src\App, Test\\: src\Test

а лучше наверно App\\: src\App, Test\\: src\Test

почему просто Test а не Test\App? у тебя ж тесты к проекту относятся