vasIvas: ноды в дереве не вызывают методов друг друга. Есть некий отдельный объект который отслеживает состояние нод (через ивенты которые имитят эти самые ноды) и дергает методы у других нод.
Что до MVC - именно логику работы с данными и логику представления данных оно и призвано разделить. Но не логику и представление. Люди начинают упрощать и потом усложняют понятия. Более того, не зная основных принципов ООП не понятно откуда все эти идеи берутся и что дают, в результате появляется огромная армия людей которые знают много но не знаю зачем и откуда это все взялось. В итоге по незнанию применяют то или иное решение не к месту или не правильно.
andreyqin: единственное чем стоит руководствоваться - масштабирование. Ваш вариант справляется с этим чуточку лучше чем вариант вашего коллеги. Проблем с тем что у вас ребенок управляет поведением парента (хотя на самом деле это не так, ни тот ни другой не управляет поведением, на основе атрибутов оных принимаются решения не больше).
andreyqin: я ответил комментарием на вопрос выше - это сродни выбора подхода к обработке данных:
У вас есть дерево нод, нужно по изменению ноды чилдрена менять аттрибут у ноды парента. Есть два варианта.
1) ваш вариант, по изменению ноды мы траверсим по дереву в поисках нужного парента и меняем атриубуты. Медленно, но нет оверхэда по память и снижаются риски течки в замыканиях. Ну и проще да, можно делигировать события и использовать все преимущества ивент балбинга.
2) хранить мэпу ребенок - парент и тогда у нас нет необходимости траверсить дерево, наиболее быстрая работа алгоритма, но большой оверхэд по памяти (в зависимости от вложенности) и усложняется реализация. Так же отпадает возможность использовать ивент балбинг и увеличивается количество листенеров что на большом дереве придет к лагам.
vasIvas: мне кажется что у вас MVC головного мозга. Все намного проще, не MVC мир един (я вообще не понимаю как вы выплыли на ООП, тут нет ничего связанного с этим). Фронтэндщикам ближе MVVM и MVP (как и всем тем кто с GUI работает). MVC (и все ответвления) это идея разделения приложения на отдельные зоны ответственности. Один слой отвечает за вывод данных, второй - за обработку пользовательского ввода и т.д. Нет смысла замарачиваться и париться по поводу соблюдение всех эттих паттернов и т.д. если в итоге вы теряете суть зачем это нужно.
Что до вопроса вверху - У вас есть структура данных древовидная. Вам нужно изменить атрибут ноды в зависимости от состояния дочерней ноды. Одна структура. Никаких классов, никаких паттернов. Просто алгоритмизация. У вас есть выбор - хранить мэпу нод - ребенок - парент или траверсить дерево по изменению ноды.
andreyqin: ну как, если .wrapper по дереву расположен сильно далеко то код будет работать эффективнее конечно. Но при единичном взаимодействии это спички.
Kir_Egorov: вам нужно хранить аккорды все, просто не в виде картинок. И хранить распальцовку. Просто отрисовывать все по мере надобности. Эдакий средний вариант.
p.s. На эту тему были работы опубликованы но я увы не нашел сходу. Я помню когда-то интересовался. Там был довольно простой алгоритм основанный на наиболее эффективном расстоянии и т.д.
Rrooom: является так как фронтэнд грубо говоря скачивается и устанавливается в браузер, выполняется на клиенте и все такое, то есть у вас происходит дистрибьюция кода фронтэнда. mysql же до клиента не доходит и остается в рамках сервера. Если же у вас mysql требуется для десктопного приложения и вы хотите его ставить вместе с оным то придется покупать коммерческую лицензию.
Rrooom: вообще интересный вопрос, так как mysql распространяется по лицензии GPL и для использования оного в коммерческих проектах есть отдельная лицензия за денежку. Но пока у вас mysql не является частью дистрибьютива вашего приложения то все хорошо. Скажем у postresql своя лицензия которая резрешает использование оной в любом виде и для любых проектов.
KOPC1886: что значит "максимально заточен"? Максимально можно заточить под SAPI но даже в этом случае php-fpm предоставляет больше возможностей (например позволяет вам сказать принимающей стороне что больше данных от вас не поступит и завершить запрос а на самом деле php еще будет отрабатывать и делать какие-нибудь левые таски - например почту отправлять).
А так проблем задать конфиг для nginx-а я не вижу. Естественно что для большинства удобнее будет положиться на поставляемые .htaccess файлики и не страдать.
vlaabra: повторюсь, array_multisort реализован на c и работает напрямую с zval контейнерами, отсюда и выйгрыш в производительности. Но так как функции на Си которая вам нужна нет, а все варианты при которых можно добиться быстрой сортировки требуют еще одного прохода по массиву и составления нового (к слову можно поиграться с array_column, sort c сохранением ключей и переколбашиванием массива) то вариант с usort остается самым быстрым.
vlaabra: strcmp не может быть медленнее. Оверхэд в основном идет только за счет вызова пользовательских функций и обращению к филдам. Именно по этой причине array_multisort чуточку быстрее собственно. Можете профайлером пробежаться и убедиться что большую часть времени php тратит на вызов замыкания или функции в вашем случае.
Так же имеет значение версия PHP на которой вы выполняете скрипт. Если есть возможность обновиться до php5.5 а лучше до 5,6 - лучше так.
Если и этого не хватает - стоит рассматривать вариант применения HHVM или переписать на Go. Но самым здравым решением было бы воспользоваться базами данных.
Что до MVC - именно логику работы с данными и логику представления данных оно и призвано разделить. Но не логику и представление. Люди начинают упрощать и потом усложняют понятия. Более того, не зная основных принципов ООП не понятно откуда все эти идеи берутся и что дают, в результате появляется огромная армия людей которые знают много но не знаю зачем и откуда это все взялось. В итоге по незнанию применяют то или иное решение не к месту или не правильно.