Иван Кондратьев

Передавайте в функцию по ссылке:

function modify(&...$vars) {
  foreach ($vars as &$v) {
    $v = trim($v);
  }
}
modify($x1, $x2, $x3);

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

Зачем нам нужны контроллеры или различные представления данных

Зачем нам в принципе контроллер? Что он делает? Для упрощения не будет воспринимать контроллер как "один объект" и вместо этого представим себе его как целый слой. Так же заменим слово "модель" словом "приложение".

Задача контроллера - принять и обработать запрос и выдать ответ. По сути в контексте WEB наш HTTP запрос и ответ это представление, которое хочет получить клиент (браузер, мобильное приложение, SPA, что угодно). HTTP - это интерфейс пользователя (UI) для нашего web-приложения.

Например что бы независеть от реализации клиента и что бы было удобно мы передаем даты в формате iso 8601 (пример: 2016-07-14T19:40:12Z). Это удобно что бы быть независимым от реализации клиента или сервера. Но это не удобно для нашего приложения. В приложении скорее всего нам удобнее всего работать с объектом типа DateTime. То есть приложение использует абсолютно другое представление.

Мы могли бы прямо в приложении конвертить DateTime в iso 8601 но тогда мы делаем наше приложение привязанным к одному конкретному представлению, которое хочет получить клиент. К примеру по каким-нибудь причинам известным только темным богам, вам вдруг понадобится быстро прикрутить интеграцию с другим сервисом и те же данные гонять уже в RFC2822. И стало быть уже приложению нужно париться о еще одном представлении.

Мы могли бы сделать какие-то адаптеры у приложения, и дергать их в зависимости от потребностей, но тогда опять же наше приложение все еще знает о представлении, которое ему собственно не нужно. То есть у нас есть зависимость приложения от его UI что... похоже на "не лучшую идею". И тут на помощь приходит Inversion of Control.

Что такое Inversion of Control

Тут название само говорит за себя. Допустим у нас был объект A который дергал объект B, причем объект A по сути и не должен ничего знать об объекте B потому то это не его дело. Принцип инверсии контроля говорит нам о том, что в таких ситуациях именно B должно вызывать A, таким образом меняя направление потока управления. Это позволяет нам уменьшить связанность и повысить зацепление компонентов нашей системы. Так же сделав это у нас может появиться объект C который так же будет дергать объект A. Если говорить о UI - мы просто можем сделать несколько реализаций UI.

То есть если еще упростить - фреймворк должен дергать ваш код, а не код дергать код фреймворка. Тем самым мы снижаем связанность одного от другого.

Роутер и контроллеры как реализация UI

Что бы отвязать приложение от логики формирования представления, вынесем это все в отдельный "слой" и назовем этот слой - контроллеры. Точнее это будет как цепочка адаптеров. Один адаптер (фронт-контроллер по сути) получает Request и делает какие-нибудь вещи с ним. Например проверяет можем ли мы вообще делать подобный запрос. Другой адаптер вызывает роутер и выясняет какой дальше адаптер вызвать. Если следующий адаптер не вызван - надо вернуть 404-ую ошибку. Если же все пошло хорошо - мы вызываем еще один адаптер, который уже будет конвертировать HTTP запрос в какое-то действие приложения (вызов метода приложения по сути).

Так а инверсия зависимости это что?

Инверсия зависимости - очень похожа на инверсию контроля но действует чуть по другому. Проще всего будет вглянуть на картинку:



стрелочка зависимости на первой фигуре выходит за пределы нашего "модуля" и залазит в "чужой", тем самым наш модуль становится зависимым от другого модуля. Яркий пример - у нас есть например SwiftMailer для отправки почты. Нашему коду нужен просто способ отправлять сообщения, а SwiftMailer просто конкретная реализация.

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

Нужно ли соблюдать принцип инверсии зависимости в случае контроллеров?

Нет. Контроллеру нужна конкретная реализация какой-то части нашего приложения (ибо приложение главнее UI-ки), иначе в них нет особо смысла. И наше приложение вообще не должно париться о том что есть какие-то там контроллеры.

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

Это уже вопрос реализации IoC. Конкретно вы хотите получить что-то вроде Dependency Injection. Вы можете забрать зависимости из аргументов метода экшена. или аргументов конструктора контроллера.... или просто использовать контейнер зависимостей внутри контроллера.... это совершенно не важно. Контроллеры это то место где высокая связанность на компоненты фреймворка более чем допустимы.

С другой стороны у вас теперь роутинг совмещает обязанность маршрутизации и разруливания зависимостей. Сами понимаете что это как-то нарушает прицип единой ответственности. Этим может заниматься Controller Resolver какой-нибудь.

document.querySelector(".KEmoji_Block .KEmoji_Cont > div")

CIBlockElement::GetList, передать в аргументе групировки arGroupBy массив такого вида:

array(
'PROPERTY_BRAND' // Где BRAND это код свойсва "БРЕНД"
)

Потому что нужно вручную отписываться от события при уничтожении скоупа контроллера. Начните отсюда stackoverflow.com/questions/9418697/how-to-unsubsc...

$alpha = array('ONE' => '70', 'TWO' => '80');
$beta = array('ONE','THREE');
$result = array_intersect_key($alpha, array_flip($beta));
var_dump($result);

в результате:

array(1) {
  ["ONE"]=>
  string(2) "70"
}

Ох...

Для начала нам стоит прояснить что в javascript "методы" это обычные функции, которые просто привязаны к объекту. Если не вдаваться в подробности работы интерпритатора, вы можете спокойно вынести содержимое конструктора и заменить this на экземпляр объекта.

Если совсем упростить - в javascript нет "методов", у объектов могут быть только свойства. "Методы" реализуются присваиванием функции (обычно анонимной) к свойству объекта.

Теперь про this. this - это контекст вызова. Это "волшебная" переменная указывает на контекст, в котором мы вызвали какую-либо функцию. Она никак не фиксируется, и мы можем крутить и вертеть ей как хотим.

По умолчанию она указывает на "владельца" функции. Тот объект, в контексте которого мы вызвали функцию.

function foo() {console.log(this);}

function MyObject() {
    this.foo = foo;
}

var hashMap = {
    foo: foo
};

var obj = {};
var instance = new MyObject();
obj.bar = instance.foo;  // мы можем даже красть методы

foo(); // выведет window, если для браузера и мы вызывали в глобальном контексте
instance.foo(); // выведет instance так как в контексте этого объекта мы это дело и вызывали
hashMap.foo(); // выведет hashMap по той же причине
obj.bar(); // выведет obj опять же потому что мы вызывали функцию в этом контексте
foo.call('my own context') //мы можем задать свой контекст

Зачем присваивается this и используется в дальнейшем?

У функции есть своя область видимости. Ей доступны все переменные/идентификаторы которые определены в ее области видимости и выше в плодь до глобальной. То есть наши обработчики событий будут всегда видеть переменные объявленные в конструкторе. Причем именно то что было на момент вызова конструктора (то есть сохраняется во времени даже после завершения работы функции). Это к слову является типичной проблемой мемориликов, так как иногда люди забывают почистить за собой ссылки на объекты.

У нас конечно есть еще функция bind, которая позволяет явно зафиксировать контекст, но иногда удобнее так.

Именно за счет областей видимости функций в javascript мы достигаем инкапсуляции, скрываля приватные штуки внутри нашей области видимости и выплевывая наружу только то, что нужно. Самая настоящая инкапсуляция, модификаторы доступа в этом плане - просто кастыли (хотя для восприятия они проще).

var data = $.param({
                зфкфьі:  ["apple", "potato"] ,
               
            });

что это?

$http.put('http://*****/mongorest/control/get-menu?'+ data)

ммм... почему у вас данные в query string ложатся а не в тело запроса? Как смысл тогда PUT запрос делать?

Насколько я помню у монги нормальное REST api.

Должно быть как-то так:

$http.put('/some/url', {
    someKey:  ["apple", "potato"] ,
}).then(function (response) {
    // не пользуйтесь .success/.error
}, function (reason) {
    // пользуйтесь только промисами.
});

то есть никаких извращений и подоброго. И не пользуйтесь $.params. Вообще. Для query string у angular есть отдельный параметр в конфигурации запросов.

$http.get('/something', {
    params: {
         query: 'param'
    }
}

Советую подучить английский. Я уверен что потом тебе придётся встретится ещё с кучей документаций, у которых вряд ли будет перевод.

Возможно как то можно получить имя роута предыдушей страницы

Возможно получить реферер предыдущей страницы.

и воспользоватся $this->redirectToRoute()

В случае с реферером вам не этот метод будет нужен, а $this->redirect().
Хотя, например, вот здесь есть несколько костыльная альтернатива.

twig.sensiolabs.org/doc/extensions/intl.html#local...

Нет никакого порядка в изучении HTML и CSS касательно номеров. Забудьте о номерах, читайте последние версии рекомендаций и спецификаций, тем более вполне возможно, что номера вообще отменят, а единой спецификации CSS уже просто нет.
HTML и CSS изучаются почти параллельно, с небольшим лагом.

К изучению Javascript приступайте после ощущения минимальной уверенности в знаниях в HTML и CSS. ИМХО лучше изучать нативный Javascript, поскольку библиотек много, не говоря уже про фреймворки типа Angular.

Что за странный вызов вне аттрибутов?
{{ form_enctype(form) }}