vladamir smertniy: я не сервисную архитектуру предлагаю, я предлагаю регистрировать контроллеры как сервисы. Если они зарегистрированы как сервисы вы сами можете спокойно разруливать что куда там передается в конструктор, хоть App хоть только то что нужно. Ну и опять же вы можете сделать одну фабрику для всех контроллеров если хотите.
Далее все происходит ровно по вашему сценарию. Вы прописываете какой метод какого контроллера-сервиса дернуть, далее уже на основе рефлексии будет произведен подбор того что вам там нужно, App, Request или еще чего...
В целом же вместо всех этих извращений реально лучшим решением будет сделать сервисный слой и тонкие контроллеры, тогда их можно будет просто как замыкания использовать и не париться.
jetu: да, это более чем нормальный генерируемый код. Хотите оптимизировать - вынесите это в метод. По другому эту штуку реализовать довольно проблематично, только если в полифил запихнуть, что в прочим вам никто не мешает сделать. Да и на самом деле важно только то что слева.
Что до Set/Map/WeakMap и т.д. они поддерживаются полифилами, в принципе проблем с их использованием не будет, разве что поведение только эмулируется... Но зато где-нибудь через годик определенный процент разработчиков смогут это дело дропнуть и юзать в нэйтиве.
jetu: вот ейбогу, со скоростью "генерируемого" кода проблем нет вообще никаких. И по поводу "до жути много" - так же сомнительно. Без конкретики (что именно для вас генерит много кода, модули? есть esperanto для сборки в прод, с ним выходит минимум кода, генераторы - не сильно много кода и по производительности проблем нет никаких, классы - гененирует ровно столько когда сколько вышло бы пиши руками, проблем с производительностью не может быть) это просто пустой разговор. Я использую babel уже месяца так 4 и проблем пока нет, а тот профит который он дает в плане скорости разработки и повышения читабельности кода слихвой окупает любые мелкие неудобства в виде необходимости транляции кода.
Герман Ющенко: в выборе CMS я не силен - я одинаково ненавижу их все (разве что wordpress вызывает у меня совсем уж неконтролируемые приступы ярости). Посему мало с ними работал...
Герман Ющенко: дырки можно всегда оставить, особенно если расширения какие ставить и т.д. Скажем если не юзается какой-нибудь twig/blade в качестве шаблонизатора, риск появления XSS уязвимостей увеличивается, хотя использование этих шаблонизаторов ни разу не гарантируют безопасность в этом отношении.
Словом все упирается в квалификацию кадров. Опять же, дешевле взять разработчика подешевле и потом организовать ревью/анализ безопасности или что-то в этом духе. Но в этом есть смысл если вы планируете что-то серьезное.
Так же дам вам совет - почитайте чего по организации разработки, например для вас лишним не будет узнать что такое MVP. Я много раз видел как начинающие предприниматели наступали на эти грабли, фигачили проект и постоянно откладывали релиз.
Герман Ющенко: разработчик может пропасть, умереть, исчезнуть, потрубуются еще разработчики, вы можете не сойтись в цене, у разработчика просто не будет хватать квалификации что бы делать все вовремя...
Ну вы меня поняли. Популярность решений снижает риски. А с такими формулировками о квалификации работников говорить не приходится. Да и вы насколько я помимаю не особо "в теме" ведения проектов, так что все будет очень весело.
Герман Ющенко: а да, фреймворки - лучший вариант на перспективу, при условии квалификации исполнителя И популярности выбранных решений, ибо можно в один прекрасный момент напороться на факт что этот квалифицированный чувак сделал вам проект на никому неизвестном фреймворке или малоизвестном фреймворке, что чревато отсуствием дальнейшей поддержки оного и выльется в существенные траты в будущем.
Герман Ющенко: ну скажем так, если человек не называет название фреймворка - то это скорее всего какой-то самопис и тут лучше отказаться. Уточните что за он, может будет толк. Пока лучше Drupal.
Короче основной посыл - фреймворки - лучший вариант на перспективу при условии квалификации исполнителя (а это довольно дорого).
babel.js, и не нужно филосовствовать на тему "поддерживаемого браузерами". Это между прочим рекомендованный подход со стороны разработчиков самих браузеров.
Сергей Николаев: контроллер - это объект, просто дергайте публичные методы. vm это контекст объекта, а значит что все что в vm определено - методы и свойства этого объекта.
Сергей Николаев: если она не передана в vm - то это приватная функция и нечего ее дергать. Ее стало быть можно дернуть либо дернув какой-то публичный метод либо он дергается из конструктора.
Назар Мокринский: читаем третий пункт. В целом на странице может вовсе не быть картинок или между каждой нодой всунуто по комментарию... или по десятку... мало ли. Но даже в этом случае это все спички.
Далее все происходит ровно по вашему сценарию. Вы прописываете какой метод какого контроллера-сервиса дернуть, далее уже на основе рефлексии будет произведен подбор того что вам там нужно, App, Request или еще чего...
В целом же вместо всех этих извращений реально лучшим решением будет сделать сервисный слой и тонкие контроллеры, тогда их можно будет просто как замыкания использовать и не париться.