Кирилл Несмеянов: если у тебя 100500 зависимостей то у тебя что-то не так с архитектурой (слишком высокая связанность). Мое личное правило - стараться держать зависимости под контролем (в количестве желательно не более 3/4-х). Причем "дабл диспатч" - это тоже зависимости.
p.s. для 100500 аргументов в конструкторе существуют такие штуки как билдеры.
1) используйте классы, PSR-4 и автозагрузчик composer. Никогда не подключайте "файлы" сами.
2) я намекаю вам что возможно то что вы называете "моделью" ею не является... точнее это лишь часть модели (модель состовного элемента - вполне себе валидная модель, но нам нужна модель системы и тот ее кусочек который нужен этому контроллеру).
3) почитайте про инверсию контроля, инверсию зависимости. Фреймворк дергает ваш код. Код контроллеров дергает модель. Модель можно "достать" из контейнера зависимости например. Рекомендую глянуть PHP-DI, у него под slim есть готовый пример: https://github.com/PHP-DI/Slim-Bridge
4) в целом если не придераться - то как вы описали - так и должно быть. Нюанс только в том откуда вы достанете шаблонизатор и прочие вещи. Опять же ссылку я дал.
roskoshinsky: это не недопустимо, просто это нужно только в рамках полифилов.
Основная проблема - вы модифицируете прототип глобального объекта. То есть если у вас будет пакет который так же добавляет метод any то будет маленькая коллизия. В Ruby мире например это неслабая проблема.
volumes - для того что создает контейнер и то что вы хотите пробросить на хост. То есть это данные которые генерируются контейнером. Пример - пользовательские данные. Вы я думаю хотите что бы пользовательские данные жили дольше чем контейнер (например при обновлении старый контейнер и все что не в волумах уничтожается).
Если хотите жестких примеров использования и наполнения волумов - посмотрите реализацию контейнера для postgresql. Там при старте котнейнера создаются базы данных, схемы и т.д которые мы явно хотим хранить долго. Там для этого весьма занятно реализован энтипонит для контейнера.
npm install нужно делать либо ДО сборки образа контейнера либо ВО ВРЕМЯ сборки. То есть вот та самая директива ON BUILD она как раз для этого. И это своего рода гарантия того что после сборки образ будет содержать всегда одни и те же зависимости.
abberati: system.js это не эмуляция. это полноценный загрузчик модулей. И для production он подходит (с маленькой ремаркой - http2 only). Ну и опять же есть бандлер под system.js.
webpack - сам пока использую его и думаю новые проекты уже вести под system.js. webpack и его dev-server это прошлое. system.js и сборка на клиенте + http2 dev server решает почти полностью большую часть проблем инкрементной сборки из коробки.
Никто не спорит что можно, просто это не "включил и работает" а "изначально надо закладывать в архитектуру приложения".
> платить за это не нужно
если не брать расходы на инфраструктуру, вы как минимум платите своим временем. Я не знаю как у вас, а у меня час моей работы стоит больше чем месяц использования сервисов. И скорее всего мне придется потратить пару десятков часов в начала + раз в пару месяцев тратить еще час на решение различных проблем. А это существенно дороже использования сервисов. Ну и опять же это задает определенный оверхэд в том плане как мы пишем приложения.
Так что "серверсайд пререндеринг" не бесплатный ни в коем случае.
protasovmikhail: мы можем написать сверху еще один класс который будет инициализировать ваши объекты, и он будет загружать конфиги (возможно через другой объект - cnf о котором вы говорили), и он будет создавать инстансы объектов по требованию. Тогда наши классы не будет ничего знать о том откуда конфиги берутся, и мы это можем потом быстро поменять (причем не для всех а для части системы, мало ли). Связанность уменьшается и у нас появляется огромный простор для будущих изменений (которые не будут затрагивать то что у нас уже работает). Ну и еще жирный плюс - тестировать такие объекты удобнее.
То есть вся соль этих загонов добиться соблюдения простого правила в разработке - работает - не трогай :)
именно по этому все клевые чуваки делают систему из очень маленьких и узкоспециализированных объектов. Что бы вместо "правок" (ибо сломать мы можем только тогда когда вносим правки в реализацию) можно было выкинуть один объект и заменить другим. При этом важно снижать связанность что бы изменения в одном объекте затрагивали как можно меньше других объектов. С такой системой банально удобнее работать. А при должном опыте создание всей этой тучи объектов не занимает лишнего времени.
protasovmikhail: в том то и прикол - конструктор только принимает значения, а вот этот cfg->load должен быть вызван ДО. Inversion of control и все такое.
protasovmikhail: наследование - для устранения дублирования кода и достижения полиморфизма подтипов.
Класс в конструктор ПРИНИМАЕТ конфиг загруженный кем-то отдельно. Мы же про ООП да? А когда все и вся имеют доступ ко всему когда ходят и никакого разделения ответственности - это старый добрый процедурный код.
Керим Бердимырадов: так а что не так? вы можете просто стандартными средствами декораторы отключать, только через датабиндинг. А так вы можете получить доступ к массиву валидаторов ngModelController и поменять там чего.
