Евгений Попов: я все же правильно вас понял, без фреймворков, по старинке или при помощи библиотек (благо с каждым днем в js с этим все лучше и лучше) но на ES6, что позволит структурировать код и не завязываться на определенной инфраструктуре. Но это все круто только звучит, по факту все пока не так хорошо.
и как-то это странно, вы таким образом не соблюдаете ни одного из ваших пунктов и вам все придется делать самому, и поддерживать самому. Даже с учетом того что вы возьмете отдельные библиотеки - смысла писать новый бойлерплейт из которого вырастет свой фреймворк малова-то. Хотя возможно вам так будет удобнее.
Иван Дамаскин: я не случайно обернул все в тег script. То есть мы просто все генерируемые данные запихиваем в constant/value модулей в самом шаблоне, а наше приложение делаем зависимым от этого модуля.
Если не гнушаетесь грязных штук - есть еще ng-init, оно делает то что вам надо но это оооочень плохой способ.
Александр Евгеньевич: вот в последнем предложении моего последнего комментария я уже говорил что вы таким образом позволите случайно нарушить целостность в базе. В этом случае просто при выборке по id будет возвращаться null.
igormukhin: это не ок подход, так как это все же разные yaml.
wittyrider: у меня все (инвентори, ключи, переменные) хранятся в gpg архиве подписанном моим публичным ключем (+ публичным ключем CI-ки). В итоге доступ только у меня и у того у кого есть доступ по ssh на ci сервер.
по поводу parameters.yml - я бы порекомендовал рассмотреть вариант с .env файликами и настройкой через параметры окружения (симфони это умеет). В противном случае вам надо просто генерить parameters.yml из шаблона.
Александр Евгеньевич:
1) если у категории может быть только один родитель, то можно в одном файле все хранить. Тогда преимущества будут, иначе да, как-то странно. Работать со всем этим делом через репозиторий.
2) при many-to-many мы просто будем использовать не доктриновскую коллекцию а свою. И это будет просто как еще один тип. Тогда у нас все взаимодействие объектов сохраняется и боли нету.
Ну в целом да, повторюсь, это большое усложнение и оно оправдано только когда вам критически важно иметь полный контроль над данными через VCS например. Ну короче я не вижу проблем что бы это реализовать но и профита особо не вижу. так как можно случайно нарушить целостность.
vasIvas: я много лет назад писал на as3 но мало, я считаю что аксесоры, публичные свойства и т.д. это все нарушение инкапсуляции и принципа открытости закрытости. Я их не использую.
vasIvas: ну методы в духе getSomething/setSomething, так же как и геттеры/сеттеры это полный эквивалент публичных свойств. То есть оно никак не способствует соблюдению принципа открытости/закрытости и нарушает инкапсуляцию.
В целом же это нормально, это распространенная практика, это просто в конце концов, для некоторых ситуаций это нужно, но лучше стараться не использовать это добро.
LittleFatNinja: более чем. Скорее всего автор таким образом попытался реализовать автозагрузку функций. Вместо этого лучше в composer.json прописать что бы в любом случае подключался файлик с функциями. Это при включенном opcache ничего не стоит, и не надо извращений.
