Спасибо что откликнулись! Да, узлы-братья, это те у кто имеет общего родителя, а узлы-соседи нет. Мой алгоритм можно и не понимать, так как он не рабочий, он работает только в приблизительно восьмидесяти процентах случаев.
Алгоритм (за авторством Reingold, Tilford) я и повторяю. Изначально я и делал как у них показывается, что проходил с родителя по всем узлам вниз и находил максимальный сдвиг вправо и влево... Но такого подхода есть свои минусы. Первый из них, нужно каждой ноде задавать хоть какие, но координаты, чтобы узнать на сколько соседи удалены друг от друга при обходе. Второй недостаток в том, что очень тяжело сохранять ссылки на самые правые и самые левые узлы в поддереве на каждом уровне. Все это делало его очень и очень избыточно медленным.
После я переосмыслил и понял что все тоже самое можно сделать без обхода каждого уровня.
Посмотрите на эту картинку, она отображает состояние при котором начинается расстановка. В таком состоянии все нодо выставлены правильно и максимально прижаты вправо. Мне не нужно обходить все уровни чтобы это понять. А так же я знаю на какое расстояние увеличилась сумма промежутков между узлами. Если же узлы уже были сдвинуты, такое может быть только в том случаи, если я сначала выставлю узлы с картинке, а потом, где-то на следующих шагах, я в этот же алгоритм включу самый верхний-правый. Но тогда я буду знать насколько узлы были сдвинуты по свойствам leftOffset и rightOffset.
Сергей Протько: habrahabr.ru/post/263025 статья очень интересная. А смутило меня то, что однажды у меня состоялся разговор начатый со слов о mvc, но потом мой оппонент переключился на слова, которые меня подтолкнули к мысли, что я не понимаю значения модели. Ну или он чересчур хотел сумничать, упрекнув меня что я не знаю что такое модель предметной области. И вот вчера я увидев статью на хабре и прочтя её, усомнился в понимании значения модели. Я тоже всегда думал что в mvc, модель это само приложение, данные + поведение.. Но кто его знает..
Сергей Протько: на днях прочел статью на хабре о "моделях и логике" и теперь немного в замешательстве, так как не понимаю модель из mvc это не модель предметной области?
Сергей Протько: я с Вами тоже согласен, но частично. Пока я думаю о обычном сайте на angular, то у меня все получается, но есть один нюанс. Представьте что Вам покажут работу на angular с логикой в модели, что Вы подумаете?
Но самая большая головная боль начнется тогда, когда я начну писать очень сложное приложение, в котором одной просто вью и просто модели не будет достаточно.
Если представить что в приложении будет находится 3d движок и само приложение будет иметь очень сложную логику, о из-за того, что все это сложное отправится в модель-js, хотя 3d и физические движки, это самое что не на есть представление, начнется настоящая головная боль. А сложная модель приложения в angular не предусмотрена, так как все хваленое mvc является не архитектурным, а компонентным.
То есть angular похож на компонентный фраймворк, а не на архитектурный, какие например есть в том же flash. И хочу подчеркнуть, что пусть все ненавидят flash, но он является тем, к чему вэб идти ещё несколько десятилетий.
Хотя более вероятно, что с приходом вэбасамблера js-html-css уйдут в небытия, так как любой продвинутый язык сможет написать свой один единственный вэб язык.
Сергей Протько: нет. Я говорю, что общение контроллеров, это вполне естественно. И я пытаюсь обратить внимание на то, как отклонение от естественности приводит к смешным формулировкам, чем является Hmvc. Человек описывает обычное mvc, но называет его Hmvc.
Ещё близкий пример, на мой взгляд, это mvvm. Просто так вышло, что браузерный язык разделен на три части html+css+js и его воспринимают, как три разности, относя html к представлению, а js к модели.
Например во флеш один язык во всем клиенте и по этому на клиенте реализуется "изящная-каноническая" mvc архитектура со своей моделью и представлением.
Но в вэбе из-за того что js это модель, получилось смешивание логики представления с логикой приложения-моделью. Если сейчас задать вопрос о том, что такое js, то почти все ответят, что это модель клиента. И именно по этому теряется смысл настоящей клиентской модели.
Это двумя словами если.. Хотя ещё стоит добавить, что по этой причине на клиенте отсутствует правильная модель и на её замену пришел валуеобжект, который был навеян серверистами, что даже в вики осуждается за толстый контроллер. И именно по этому и был придуман двухсторонний биндинг, который по своей философии не нарушает никаких концепций. Но если вспомнить что сама концепция биндинга образовалась на неправильной концепции толстого контроллера и ко всему этому ещё добавить Hmvc, то получается веселая история.
Сергей Протько: здесь я написал с полсотни строк, но понял что по смыслу они все разрознены, что вызвано недостатком знаний. По этому я все стер, но обязательно продолжу, когда соберу нужную информацию.
Однажды, в самом начале своего пути, я заразился одержимостью архитектуры.
Я многого не знал в своем первом языке, но в разговорах о архитектуре часто был на равных со старожилами.
Но когда я начал изучать вэб, то столкнулся с непониманием вэб архитекторов и их фразами о "незагоняйся, архитектура ерунда". От всего этого у меня в голове образовалось месиво и я решил разобраться. нашел самые истоки, первые презентационные доклады, которые подтверждали мою правоту. Но что меня по настоящему удиви, это то как люди искажают данные. Найдя английскую версию я поле в интернет гуглить что-то подобное на русском и все статьи которые мне попадались были следующие. Авторы рассказывая "неправильную версию" подтверждали её первоначальной статьей.
Это я к чему, а к тому что я почитал о hmvc и это вообще какое-то безумие. Это же ЕСТЕСТВЕННО что каждый компонент приложения это своя триада. А задумка что каждая триада общается через свой контроллер вообще *нутая. За каким фигом для каждой кнопки плодить контроллер? Ведь правильно будет создать только один контроллер и все компоненты должны с ним общаться при помощи медиатора.
А если должны общаться представления с представлениями, а модели с моделями, то они это делают через свои main. И когда у каждого из триады есть свой main, то это не какой-то отдельный *mvc, это и есть обычный и правильный mvc. Просто автор скорее всего не думал что существуют такие программисты, которым алгоритм поедания яблок нужно описывать так -
> положи в рот яблоко и съешь.
>> а если у меня два яблока, тогда как?
> положи в рот яблоко и съешь, положи в рот яблоко и съешь
>> а если у меня три яблока, тогда как?
>> *дец.
Не могу согласится, так как любое отклонение возвращает нас во времена из-за которых и придумали эти концепции. А тот факт что кнопка может управлять САМИМ ПРИЛОЖЕНИЕМ просто взрывает весь разума, пусть даже она написана САМИМ ГУГЛОМ.
Сергей Протько: Спасибо! Сам бы до конца не разобрался и так бы и делал неправильно. А ещё мой минус был в том, что я использовал русский хелп, а он значительно отличается.
Сергей Протько: добавил еще код. Он правильный? А то у меня есть сомнения о использовании рендер.
И я не понял когда выполняются formatters. Написано что после изменения модели. Но если я в блоке if устанавливаю новое значение model.$setViewValue(string), то разве я не меняю это значение в модели?
Спасибо. Тогда правильно будет так как у меня в добавленном коде? Есть ли какие-то замечания по нему? И ещё меня давно мучает вопрос по поводу директив, но я чуть попозже новый вопрос задам, но затрону в нем этот пример.
Прочитал данный вопрос и понял что не понимаю одного момента и чтобы не создавать новый вопрос, спрошу здесь.
Как все говорят, действия над элементами дом нужно выносить в директиву. И вот получается что я создаю директиву ng-input-lock и так же создаю input. Но что мне писать в таком случае в значении ng-input-lock="?".
Если Вас не затруднит, можете рассказать о последовательность создания такой директивы?
