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

colobokXXL · 10.03.2011, 15:28

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

. Основные визуальные объекты можно рисовать вручную с помощью Flash IDE (что и сделано в примере).
Прошу обратить особое внимание на следующие вещи (крайне нужен взгляд со стороны):

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

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

BaZZ · 10.03.2011, 15:44

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

Котяра · 10.03.2011, 22:32

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

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

colobokXXL · 10.03.2011, 23:19

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

Котяра · 11.03.2011, 00:12

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

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

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

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

arttag · 11.03.2011, 13:05

Цитата:

Сообщение от Котяра

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

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

Цитата:

Сообщение от Котяра

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

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

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

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

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