Ну говорить, что MV* не подходит для больших проектов это как говорить, что колеса подходят для велосипедов, но для танков не подходят. В танках тоже есть колеса, хотя и не сразу видно.
Ну по вашей логике я сегодня должен был утром идти в офис O2 и положить их отдел разработки
Да, именно, должен быть один контроллер — в случе бизнес процесса это должен быть 1 (одна штука) рутовый контроллер процесса. На последней картинке это и показано.
В больших или интегрированных системах контроллеры могут вообще лежать в отдельных частях системы, которые даже могут поставляться по отдельности или быть опциональными, или даже написанными на другом языке.
Они и не лезут, статья не о том что происходит между компонентами внутри _одного_ набора MVC, а о том, как сделать так чтобы несколько наборов не создали кашу из связей и что одного лишь MVC тут недостаточно
Представьте страничку на шаге 19 которая позволяет вам изменить данные (адрес, данные кредитки или координаты вашей бабушки) которые вы ввели на шаге 1, 2, или 4.
Без рутового контроллера придется завязываться в контроллер конкретного шага — это и есть сильная связь в данном случае (даже если это просто POST на другой контроллер — вьюшка из шага 19 завязана на формат данных которй принимает контроллер на шаге 1 (редактирующий возможно более полную версию модели)
Полезно, плюсую, только важно понимать, что root controller делает вам такую же каку, как и глобальные переменные в коде — важно уточнить, что root controller должен быть один на бизнесс процесс. Даже если он физически один, а процессы описываются в XML или где еще, — логически важно понимать что это разные контроллеры отдельных процессов.
Посыл статьи, похоже, о том, как организовать и упорядочить множество представлений, когда они так и норовят влезть друг другу в контроллеры в случаях, когда есть всякие многошаговые визарды или сложное многуровневое редактирование — это уже абстракцция повыше, чем MVC и на уровне архитектуры все таки это логика бизнес процесса.
В таком случае есть риск создать спагетти на уровне вьюшек и контроллеров. Сам если честно еле вкурил авторскую траву, началось с «MVC недостаточно, но он спас весь мир от спагетти», внезпно откуда ни возьмись модули, и тут опа — ктото куда то лезет и это плохо почему то когда система поставляется множеству пользователей (а не когда много модулей)
Медитация над картинками помогла, но логика изложения, как ни странно, похожа на то самое пресловутое спагетти. Конкретный пример бы здорово помог — A, B, C всегда плохие имена для переменных.
Спор на пустом месте, как будто псевдокод — последний в жизни язык программирования. Совершенно неважно на каком языке псевдокод, если он простой и понятный — это его главная цель.
Лично мне логичным выглядит не только выделение, но и подчеркивание ключевых слов. Есть замечательный учебный алгоритмический язык из учебника Кушниренко с русскими ключевыми словами.
Если хочется ближе к оригиналу — русский как минимум упростит понимание материала. Цель учебника — подать материал просто и понятно, поэтому логичнее использовать русский. Споры на тему «без английского никак» оставьте читателю — если ему надо будет английский, он не за ваш учебник возьмется. Как вариант — сделайте маленький словарик в приложении и дело с концом.
Отличный прецедент, если это всплывет высоко и громко, вполне можете войти в историю, как Джон Коннор информационной эпохи, решивший все споры в судах :)
Согласен, может у вас даже покруче будет, интеграция и все такое — по крайней мере не надо отдельно стартовать вотч и сервер.
А насчет руби для меня нет религиозной проблемы пользоваться гемами — ну руби ну и что, это не мешает мне им пользоваться в проектах на ноде ) Про винду не знаю — стараюсь не иметь с ней дела, на остальных осях проблем нет.
В любом случае спасибо, для меня один способ хорошо, а два — лучше
Это же JS, что мешает взять и сделать манки патч если требуется?
А такой подход через события только добавляет проблем в отладчике и повышает общий градус непонимаемости происходящего на странице.
Второй пример более подходящ, но посмотрите сами — он же просто меннее гибок. С методами вы можете послать одно и то же сообщение каждому отдельному экземпляру — на уровне языка. С событиями у вас одно жирное событие нв все экземпляры какого то класса. А что если вам в обработчике понадобится отличать экзкмпляры один от другого и логика будет зависеть от состояния обьекта? Вам придется лепить колбасу if-elseif-elseif-then. И восторг вдруг сразу куда то исчезает.
Twitter изобрел pub/sub и назвал его flight. Ну пощупаем, но вообще согласен c Goder, общение через глобальные события просто меняет кашу методов на кашу событий, и кроме того будет больше кода и меньше жизненных радостей типа быстрого перехода на определение. Вообще не понимаю мотивацию делать все через искусственные события, в ООП вызов метода — это же и есть событие, посланное экземпляру.
Для скромного количества компонент впрочем вполне подойдет, хотя не вижу особой разницы между flight и обычным паб/сабом
потому что, чтобы преупреждать о последствиях, нужно их знать, а вы, как я вижу всегда знаете наперед все последствия или рассчитываете их получить от ближайщего спеца. Мир далеко не так кругл как вы мне тут рисуете.
Да если вы всегда анализируете решение вплоть до производительности функций, мне вас только жаль
Дальше разговвривать не вижу смысла, спорить с вашей оторванной от жизни абстрактной логикой просто бессмысленно
Да, именно это и означает, неистово плюсую за смекалку, вот только в реальном мире это далеко не всегда доступная роскошь — выбирать инструмент разработки, о чем я уже написал, упомянув IE6
По моему очевиден подтвердженный приоритет.
Пишите обязательно, будет интересно
Да, именно, должен быть один контроллер — в случе бизнес процесса это должен быть 1 (одна штука) рутовый контроллер процесса. На последней картинке это и показано.
В больших или интегрированных системах контроллеры могут вообще лежать в отдельных частях системы, которые даже могут поставляться по отдельности или быть опциональными, или даже написанными на другом языке.
Представьте страничку на шаге 19 которая позволяет вам изменить данные (адрес, данные кредитки или координаты вашей бабушки) которые вы ввели на шаге 1, 2, или 4.
Без рутового контроллера придется завязываться в контроллер конкретного шага — это и есть сильная связь в данном случае (даже если это просто POST на другой контроллер — вьюшка из шага 19 завязана на формат данных которй принимает контроллер на шаге 1 (редактирующий возможно более полную версию модели)
В таком случае есть риск создать спагетти на уровне вьюшек и контроллеров. Сам если честно еле вкурил авторскую траву, началось с «MVC недостаточно, но он спас весь мир от спагетти», внезпно откуда ни возьмись модули, и тут опа — ктото куда то лезет и это плохо почему то когда система поставляется множеству пользователей (а не когда много модулей)
Медитация над картинками помогла, но логика изложения, как ни странно, похожа на то самое пресловутое спагетти. Конкретный пример бы здорово помог — A, B, C всегда плохие имена для переменных.
Лично мне логичным выглядит не только выделение, но и подчеркивание ключевых слов. Есть замечательный учебный алгоритмический язык из учебника Кушниренко с русскими ключевыми словами.
Если хочется ближе к оригиналу — русский как минимум упростит понимание материала. Цель учебника — подать материал просто и понятно, поэтому логичнее использовать русский. Споры на тему «без английского никак» оставьте читателю — если ему надо будет английский, он не за ваш учебник возьмется. Как вариант — сделайте маленький словарик в приложении и дело с концом.
А насчет руби для меня нет религиозной проблемы пользоваться гемами — ну руби ну и что, это не мешает мне им пользоваться в проектах на ноде ) Про винду не знаю — стараюсь не иметь с ней дела, на остальных осях проблем нет.
В любом случае спасибо, для меня один способ хорошо, а два — лучше
1. Берем ихний плагин
2. Cтавим гем guard-livereload
3. Делаем файлик Guardfile вида
4.
guard startПолного релоада так конечно не добиться, но статику обновляет
А такой подход через события только добавляет проблем в отладчике и повышает общий градус непонимаемости происходящего на странице.
Второй пример более подходящ, но посмотрите сами — он же просто меннее гибок. С методами вы можете послать одно и то же сообщение каждому отдельному экземпляру — на уровне языка. С событиями у вас одно жирное событие нв все экземпляры какого то класса. А что если вам в обработчике понадобится отличать экзкмпляры один от другого и логика будет зависеть от состояния обьекта? Вам придется лепить колбасу if-elseif-elseif-then. И восторг вдруг сразу куда то исчезает.
Для скромного количества компонент впрочем вполне подойдет, хотя не вижу особой разницы между flight и обычным паб/сабом
Да если вы всегда анализируете решение вплоть до производительности функций, мне вас только жаль
Дальше разговвривать не вижу смысла, спорить с вашей оторванной от жизни абстрактной логикой просто бессмысленно
поэтому я просто склоняю голову перед вашим профессионализмом