Pull to refresh

Comments 3

А вы не пробовали уже готовые mvc-фреймворки? Например, PureMVC или Robotlegs. или же вы целенаправленно отказались от готовых решений в пользу своей разработки?
Вопрос по MVC схеме: почему у вас событие об обновлении не слушается вьювером? Можно ведь использовать флексовый механизм Bindable. тогда вообще отпадает необходимость вручную обновлять визуальные компоненты.
Хотелось самим спроектировать схему взаимодействия между отдельными блоками системы. Это интересно

У нас на картинке неточность, исправлю. В основном view и его элементы обновляются через binding, это очень удобно. Но некоторые команды вызывают полное обновление view, которое контролируется engine'ом.
Очень интересный для новичка материал. Можно поучиться модульности программирования во flex / air, использованию сторонних библиотек, узнать новое об «использовании паттернов», организации последовательной обработки событий и вообще профессиональному стилю программирования. Только вот, какая бочка меда без ложки дегтя?

Я реагирую на Вашу статью как новичок во flex / air, но имеющий некоторый опыт программирования в других языках.

Помимо указанных плюсов, бросаются в глаза явные минусы. Вместо того чтобы писать собственно о своей программе, Вы пишите в основном об абстрактных концепциях программирования, имеющих разные названия в разных языках, но, по сути, являющиеся общим местом. У Вас это называется «схемой MVC», реализацией паттернов «Chain of responsibility», «Command», аналога «Memento». Хотя про паттерны я ничего толком у Вас не узнал, благо Интернет помог. Если Ваша личная заслуга в собственной реализации известных шаблонов программирования, то пишите об этом, а не о программе, которое практически никак не реализована, либо безжалостно урезана.

Я так понимаю, что известные фреймворки Вам, по разным причинам, не подошли. Вы не захотели использовать ни Mate, ни PureMVC, ни какие другие. А спрашивается, зачем? Топология Вашей «цепи» событий описана так, как будто Вы говорите о чужой технологии, а не своей собственной. Вместо нее вполне можно использовать родной механизм событий, реализованный во флэксе по умолчанию. Тем более, для такой простой «программы», как Ваша.

Про свою программу Вы практически ограничиваетесь парой фраз в паре мест. Типа, «непонятно, но здорово!». Ваша бизнес-логика нарисована странно и, вероятно, не соответствует действительности. Почему-то не показаны связи вьюеров и билдеров с энджинами, а чтобы понять работу конвейера по обработке событий, нужно, скорее всего, изучать Ваш код непосредственно. Однако он не компилируется, поскольку не все файлы Вами предоставлены, зато есть явно не нужные, типа сертификата и текстового файла к нему. Чтобы скомпилировать Ваш проект, нужно докачивать файлы из интернета, а один файл можно получить только хакерскими методами. Наверно, желающих компилировать Ваш проект было не слишком много.

Теперь собственно про Вашу программу. И если реализация на уровне кода сделана достаточно профессионально, то на уровне идеи – ниже всякой критики. И чему Вы гордитесь? Что отображаете профессионально две таблицы (грида), в которых можно рисовать «бревна»? Больше ничего Ваша демо делать не умеет. О чем это говорит?

Во-первых, о том, что Ваши «манагеры», не умеют работать с клавиатурой, им даже числа в поля надо вводить мышкой. Это, судя по скринам, в реальном опубликованном коде нет даже этого. И эти «манагеры» управляют профессиональными программистами?

Ясно, что функционал программы Вы покоцали. Чтобы никто на него не позарился? Но именно этот функционал идейно очень слаб, а сильна именно формальная сторона организации программы, которой воспользоваться можно без проблем. Правда, я бы Вашей последовательной обработке событий предпочел бы параллельную, реализованную в Мэйт. Если вьюер3 или энджин3 или дайэтер3 захочет передать сообщение 2-кластеру или как Вы там его называете, то как он сможет это сделать по Вашей схеме? В Мэйт, либо в родном обработчике событий флэкс это делается без проблем.

Во-вторых, Вы что-то намекнули про: «Группировать проекты по заказчикам, добавить возможности перетаскивания связей между проектами, перетаскивания сотрудников и проектов по папкам.. .». И вежливо промолчали дальше. А ведь это уже типичная база данных, которые удобнее решать именно средствами базы данных без понтового драг-энд-дропа.

В-третьих, а с отчетами то как? Они не нужны? Или выгружаем все в эксель и печатаем там? Это профессионально?

Знаете, подобные Вашей, базы данных реализуются в два хлопка на старой доброй 1С77. Да, там нет понтов с «перетаскиванием» мышкой, и «бревен» в гридах, но зато можно элементарно строить отчеты и легко учитывать сложнейшую схему взаимосвязей сотрудников – проектов – заказчиков – расчета стоимости – печати и т.д. и т.п. А какие у Вас преимущества, кроме реализации блажи бестолковых менеджеров? Откуда у них деньги оплачивать Ваши проекты? За счет фирмы? С такой эффективностью, зачем они вообще нужны?

Прошу не обижаться за критику, ничего личного, исключительно признание Вашего профессионализма, там, где он есть и недостатков, там, где они тоже присутствуют. А одно без другого не бывает, как две стороны одной медали.
Sign up to leave a comment.