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

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

А ещё можно забыть вообще проект начать делать. Такое тоже бывает.

не, ну я не знаю,спрашивал, если вдруг уже есть решение

лучше писать

не так уже и много методов

или дописать самому

https://github.com/symfony/symfony/issues/19612

еще вот так можно попробовать

name_prefix: api_v1_

/** *@Route('/show', name="article_show") */ такая запись обязательна для всех экшенов, правильно? /show url a name это как маршрут указан в конфиге?

это урл и имя

вернее uri

в доках же всё есть)

Доки - для слабаков!

@the_coder uri маршрута может поменяться во всём проекте, поэтому нужно ссылаться по имени

@CawaKharkov по ссылке возможно то, что нужно. Помню в рейлс было что-то подобное вложенным ресурсам

ай, данунах, вручную набью?

без разницы куда класть assets: в app или AppBundle?

имеется ввиду не откомпилированные, не минифицированные и не аглифицированные

ну если ты не собираешся дистрибутить свой бандл — то да

ок, бест практис вроде в бандл рекомендует

в бандл приложения

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

ну вот тоже верно. А учитывая, что АппБандл и так забит директориями, то наверное имеет смысл хранить в app.

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

Бест практис не рассчитывает на то, что ты будешь опенсорсить. Он рассчитывает на то, чтобы тебе проще было с проектом работать в будущем.

Если речь о Symfony Best Practices.

Главное не путать с правилами Symfony Contributing.

В принципе так сказано: Symfony developers have traditionally stored these assets in the Resources/public/ directory of each bundle. А эти *Resources/public/* есть и тут и там

в доках так и написано, так и сделал :)

тут тред не хилый по этому поводу https://github.com/symfony/symfony/issues/14096

вот это вот весомый агрумент (выражения короче): Why do templates live in app/ and not in src/? When rendering a template, there are a few options to specify the path: a path relative to the app/Resources/views directory, a template logical name or an absolute path. From these options, the relative path is the easiest (AppBundle:static:homepage.html.twig vs static/homepage.html.twig vs /.../static/homepage.html.twig). That's why the best practice1 is to put them in app/.

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

со всеми ресурсами

https://gnugat.github.io/2016/03/16/ultimate-symfony-skeleton.html

интересная статейка, надо почитать

не очень красиво {% javascripts '../app/Resources/assets/scripts/some.js' %}

куда можно сохранить константу директории ../app/Resources/assets/, чтобы можно было достать её из темплейта? в parameters?

пардон, достаточно было сделать так: assetic: read_from: %kernel.root_dir%/Resources/assets/

Any suggestions for final year project Computer Science?

social network))

this is must be a neural network in 2016, not social)

social network for people who build social networks

http://cs5.pikabu.ru/images/big_size_comm/2015-10_5/1445633039113787759.jpg

this is must be a neural network in 2016, not social)

Social neural network where every people can pretend that they are neurons.

Nice ideas, and what about Micro Volunteering Management System?

why micro and why volunteering?

and what to manage there?

Suppose I have 1 hour a day, and I want to spend it online in doing something as a charity. Then there is NGO/Charity which need a programmer who can develop their application. The platform between them will be MVS

Non-profit NGO or Charity.

And Neural networks are beyond my approach. I'm doing my project alone.

if you have 1h a day you can't write anything

Just assume. There are many tasks that can by done in 1h.

The users of my application will not only be developers, there will be teachers, students, accountants and a lot more.

Ребята как правильно работать с ресурсами? В шаблонах пишем <img src="{{ asset('images/NVision_logo_130x40.png') }}" /> или лучше использовать assetic и вот так {% image 'images/ajax_loader_64.gif' %} <img src="{{ asset_url }}" /> {% endimage %}

Да, мне сюда)

Всем добрый вечер. Интересует, кто как делает и что думает по поводу модели и сущности? Или тупо все нужные методы в сущности объявить и не парится? Встречал мнение, чтобы entity должна быть описана только сущность (поля, геттеры, сеттеры), а все остальное в модели (наследованием, например)

ну мне ребята посоветовали, всю работу с таблицами выносить в репозитори,а в модели только описание полей и геттеры/сеттеры

ну мне ребята посоветовали, всю работу с таблицами выносить в репозитори,а в модели только описание полей и геттеры/сеттеры

Ну у меня есть объект - альбом. В нем есть список фотографий (объект фотография). Мне нужно вернуть - главное фото. Можно сделать как ’$album->getPhotos()->first();’

А можно $album->getFirstPhoto()

ну мне ребята посоветовали, всю работу с таблицами выносить в репозитори,а в модели только описание полей и геттеры/сеттеры

Блин. Туплю. Спасибо ) только понял о чем вы написали )

я сам еще изучаю симфони, поэтому точно сказать не могу, как лучше. Я все запросы к БД делаю в классе repository http://symfony.com/doc/current/doctrine/repository.html А что говорит по этому поводу Best Practices?

я сам еще изучаю симфони, поэтому точно сказать не могу, как лучше. Я все запросы к БД делаю в классе repository http://symfony.com/doc/current/doctrine/repository.html А что говорит по этому поводу Best Practices?

Не , мне не запрос нужен - мне действие над объектом чтоли

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

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

Ну собственно в этом и вопрос . Точнее кто как делает и почему.

Ребята, будем благодарны если разъясните этот вопрос

Где и почему именно там производить работы над объектом БД. Есть класс сущности (геттеры/сеттеры), Так вот выборки, обновления, удаления производить в этом же классе или делаем репозитори?

Паттерн Репозиторий. Сущность хранит только состояния

Где и почему именно там производить работы над объектом БД. Есть класс сущности (геттеры/сеттеры), Так вот выборки, обновления, удаления производить в этом же классе или делаем репозитори?

Использовать репозиторий однозначно. По поводу логики рекомендуется использовать сервисы.

Где и почему именно там производить работы над объектом БД. Есть класс сущности (геттеры/сеттеры), Так вот выборки, обновления, удаления производить в этом же классе или делаем репозитори?

active record или data mapper нравится больше?

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

Я пошел немного по другому пути: сущность - просто дата-маппер, только связь с базой, в репозиториях методы, которые работают с базой/сущность, выборки всякие. В сервисы выношу самую общую логику, но почти под каждую сущность делаю еще отдельный объект, где логика, которая относится к сущности. Эти объекты выношу не в сущности, а забираю через фабрику, а фабрика в свою очеречь при инстанцировании передает объекту через кучу зависимостей - контейнер, ентити-менеджер, ну и еще там внутренние сервисы, мета-данные о сущности и т.д.

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

тогда скорее всего придется использовать doctrine, а она классический data mapper

Я пошел немного по другому пути: сущность - просто дата-маппер, только связь с базой, в репозиториях методы, которые работают с базой/сущность, выборки всякие. В сервисы выношу самую общую логику, но почти под каждую сущность делаю еще отдельный объект, где логика, которая относится к сущности. Эти объекты выношу не в сущности, а забираю через фабрику, а фабрика в свою очеречь при инстанцировании передает объекту через кучу зависимостей - контейнер, ентити-менеджер, ну и еще там внутренние сервисы, мета-данные о сущности и т.д.

шо опять ddd?!

что такое ddd

Domen driven development

Паттерн проектирования

шо опять ddd?!

Почти. Честно говоря, ка по мне, то все же в каждом проекте реализуется какая-то смесью И каждый раз по разному рецепту приготовленная. Под нужды. :)

ddd эта очередная модная хрень. еще год назад всех перло от soa и тут бац - уже не модно. ddd не паттерн ни разу, скорее методология. основная суть: разберитесь с бизнес процессами и нахерачте к ним 10500 классов и главное помните что сеттеры уже не модно.

Так потому и не стоит заморачиваться четкими формулировками. В одном проекте уместен один подход, в другом - другие задачи и проектируется все по другому.

вообщем каждый делает так ему удобно :)

Сервисы - то что мне надо ) модель хранить в сервисах значит