Фреймворк «Конструктор»
 

В архиве лежит проект небольшого фреймворка (в том числе и файл проекта для FD). Данный фреймворк создавался для упрощения (и ускорения, само собой) процесса создания разного рода конструкторов, в том числе людьми не сильно разбирающимися в технических подробностях.
Знакомство лучше всего начать с просмотра SWF-файла (там уже приведён простой пример использования данного фреймворка, заодно на этом примере можно посмотреть все настраиваемые параметры конструктора).
В главном файле Main.as имеется возможность изменять различные настройки конструктора, фактически, это единственный файл, где необходимо вносить изменения в код. Во всех файлах проекта есть комментарии, надеюсь, понятные :). Основные визуальные объекты можно рисовать вручную с помощью Flash IDE (что и сделано в примере).
Прошу обратить особое внимание на следующие вещи (крайне нужен взгляд со стороны):

• Организация классов (архитектура самого проекта)
• Использование событий (особенно это касается реализации Глобальных событий, класс EventBroadcaster)
• Удобство использования для создания своих собственных конструкторов.
• Любые другие сферы критичные для жизнеспособности данного проекта.

Это некоммерческий проект, в дальнейшем (если идея окажется жизнеспособной) он будет выложен в сети под какой-нибудь свободной лицензией.
Заранее большое спасибо!

Не совсем понятно для чего собственно этот фреймворк нужен и что именно он упрощает. Описание и готовый swf не несут особого просвещения. Лично я не нашел в себе мотивации блуждать по вашему коду вникая в суть предназначения :)

Это мега супер фрэймворк всего наверное..
Просто набор библиотек и архитектур, которыми пользовался автор.
Вот что такое "конструктор" я так и не понял.
UPD. посмотрел. это какой то набор для простейших тестов.

архитектура неверная.
то что классы лежат в src не делает src пакетом. пакетов как таковых нет вообще у вас.
всё зашито в код. ничего расширить нельзя. у вас не фрэймворк а просто одна из реализаций тестов. не шибко интересная.
по хорошему, нужно выносить все данные теста в xml, тогда, может быть кто-нибудь заюзает для динамического создания тестов.

Корни идеи идут из создания обучающих и проверяющих элементов для дистанционного обучения (это основная сфера применения на данный момент).
Что можно сделать на базе этого фреймворка?
1) визуализировать любые задачи типа: классифицируйте, рассортируйте, упорядочите, составьте (лучшего названия, чем "конструктор" для задач, где из одного поля нужно перетащить элемент в другое, я не придумал, если у вас есть идеи по этому поводу, с удовольствием их приму)
2) "нарисовать" любой внешний вид конструктора: поля, в которые кладутся элементы, сами элементы, кнопки, окна уведомлений.
3) задать любой удобный алгоритм вычисления оценки за сборку конструктора
4) задать (и вполне удобно и быстро настроить) сетку в каждом поле, к узлам которой будут прилипать элементы после перетаскивания
Теперь о том, как это сделать.
В главном файле Main.as есть вводный комментарий, там описаны общие моменты. Это единственный файл, в котором задаются уникальные для данного конкретного конструктора параметры (количество полей, правильный ответ для каждого поля, количество попыток, параметры сетки для прилипания и т.д.). Возле каждого параметра дан подробный комментарий, что и для чего.
Итого, после написания этого небольшого (а не “мега супер”) фреймворка, на составление примера (который лежит в архиве, просто как маааааленький пример того, что можно сделать) я потратил 1 час вместе с придумыванием и прорисовкой всех элементов (если бы на украшательства не заморачивался, потратил бы около 20 минут).
Про xml и "одна из реализаций тестов"
Пример реализации с упорядочиванием и разбиением на категории - это уже не простейший тест с выбором вариантов ответа (опять же, если у вас есть идеи, как перечисленные мной выше задачи архитектурно представить другим интересным способом, поделитесь, скажу ОГРОМНОЕ СПАСИБО!).
В текущей реализации конструктор может быть использован для обучения. Теперь по поводу контроля (запоминания действий пользователя и его оценки). В ближайшее время допишу часть фреймворка, отвечающую за интеграцию с LMS Moodle через SCORM и нестандартный тип вопроса “Flash”.
Кроме того, это только начало развития фрэймворка, дальше планируется реализовать все части примерного такого практикума и дальше расширять типовые компоненты в разные стороны (электротехника, геометрия и т.п.)

Вот вы говорите что в Main нужно прописать всего навсего пару значений.
Почему бы эти пару значений и остальные украшательские данные нае вынести в отдельный xml файл? Который могут менять люди не знакомые с флэш? Или который будет генерится сервером по БД?
Дизайн можно и в отдельный swf ресурсов выносить. Представьте: нужно сделать 2470 тестов. Для каждого генерить свой swf?
А тут вдруг поменяли дизайн.. всё перегенерировать.. или вдруг вы решили по Scorm работать, а в движке это не прописано.. или баг какой обнаружили..

Я сам разрабатывал систему ЭУМ по математике - т.е. был главным разработчиком фрэймворка и выдавал задания/контроллировал работу 20 контент программистов, не считая тестеров. Более 2000 модулей (причём модули могли включать в себя другие модули, другие тесты, динамичские задачи, был реализован Scorm, был ввод мат формул, графики, и куча другого интерактива)
Поэтому я знаю о чём говорю. Все перечисленные проблемы испытывал на своей шкуре,пока нормально не сделали систему модулей.

Ваш пример на фрэймворк не тянет.

Вообще система ЭУМ требует отдельного разговора - фигня это всё и полное непонимание технологий (я про министерство образования и про Каталог электронных образовательных ресурсов говорю)
Старпёры и бюрократы. Но деньги пилить любят.

Пока не сильно. Хотя момент спорный, но это совсем не то направление, в котором бы хотелось, чтобы обсуждение ушло. И когда там будет гораздо больше всего, изменения вносить уже будет сложнее. Обратную связь неплохо получать на разных этапах...

Все же задачи немного разные. Если я правильно понял, у Вас была задача сгенерировать очень много достаточно однотипных решений. Я глянул по-быстрому КМ-овские, может черезчур по-быстрому и так получилось, что попал в основном на задания с выбором ответа, короткий ответ и вписать слово. Для этого всего действительно абсолютно верно все, что Вы сказали. Но нам вот именно это не нужно. И пока не нужна генерация очень большого числа простых однотипных решений. Подобные типы заданий у нас покроются возможностями Moodle. Нам же нужно делать относительно штучные решения типа тех, которые в ютюбовском ролике. И интегрировать это все с Moodle-ом. Эти задачи и решаем. Под них и начали разработку типовых гибких решений, чтобы потом на основе них, возможно, получился полноценный фрэймворк.

Т.е. мы не хотим осчастливить всех и вся и сделать суперуниверсальный фрэймворк. Хотим создать инструмент для себя и для тех, кто будет решать схожие задачи. И пока у нас основная цель была - гибкость в создании концептуально похожих, но при этом визуально разных упражнений.
Пример: разбросать по двум вертикально расположенным категориям без учета очередности, одно горизонтальное поле с учетом очердности, заполнить таблицу и т.п. Варьируется достаточно много параметров, не говоря уже о алгоритме вычисления оценки. И так сходу не очень понятно, как тут сильно поможет внешний XML. В перспективе он станет таким монструозным, что не то что облегчать не будет, а только проблемы новые создаст.

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