Разработка:Идеи

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

Список

Школьные журналы

Изменения в статусах присутствия/отсутствия на уроке

Краткое описание: Изменить статусы присутствия в таблице schpresences: поле present должно содержать не числовые значения 1 или 0, а enum-значения "was" и "away". Ноль сложнее отличать от отсутствия записи из-за неявного приведения типов в PHP.

• Какие преимущества даст осуществление этой идеи? Станет возможным легко отличать 2 разных случая: отсутствие записи о посещении ученика в таблице, и отсутствии ученика на уроке.

Подсказка по темам урока в школьном журнале

Краткое описание: В левой части журнала (там, где выставляются оценки) при наведении мыши на число сделать всплывающую подсказку, соответствующую теме урока.

• Какие преимущества даст осуществление этой идеи? Навигация по журналу станет более удобной.

Редактирование всех оценок одного ученика по одному предмету

Краткое описание: Предусмотреть возможность редактировать оценки не только всех учеников по одной дате, но и все оценки одного ученика по всем датам.

• Какие преимущества даст осуществление этой идеи? Можно будет редактировать все оценки одного ученика без перезагрузки формы
• Каких ресурсов это потребует? небольших: требуется незначительно изменить функцию отображения журнала. Не более 1 часа на кодирование и тестирование.
• С какими трудностями мы можем столкнуться?

Редактирование оценок совмещенное с просмотром журнала, редактирование старых оценок по клику из того же интерфейса.

Краткое описание:

• Какие преимущества даст осуществление этой идеи?
• Каких ресурсов это потребует?
• С какими трудностями мы можем столкнуться?

Правильная фиксация замен

Краткое описание:

• Какие преимущества даст осуществление этой идеи?
• Каких ресурсов это потребует?
• С какими трудностями мы можем столкнуться?

Механизм "билетов на замены" с кодами доступа для проведения замен без санкции завуча в системе

Краткое описание:

• Какие преимущества даст осуществление этой идеи?
• Каких ресурсов это потребует?
• С какими трудностями мы можем столкнуться?

Замечания по ведению классного журнала. Проверка журнала по результату четверти.

Краткое описание:

• Какие преимущества даст осуществление этой идеи?
• Каких ресурсов это потребует?
• С какими трудностями мы можем столкнуться?

Отметка посещаемости без расписания

Краткое описание:

• Какие преимущества даст осуществление этой идеи?
• Каких ресурсов это потребует?
• С какими трудностями мы можем столкнуться?

Школьные табели (i-Школа)

• Возможность экспорта данных для тарификации (по постоянным учителям нагрузка в третью неделю месяца, по совместителям - кол-во отработанных часов)
• Формирование приказов на изменение нагрузки у постоянных учителей если изменилось по сравнению с предыдущим месяцем.
• Дать возможность завучам и преподавателям самостоятельно сформировать свои требования к FDO, пусть они напишут, что им нравится и что они хотели бы улучшить. Есть отличный сервис для таких вещей [1] . Предлагаю использовать его.

Профессиональная переподготовка (ЮРГУЭС)

Номера дипломов/свидетельств/сертификатов

Справочник programmsbcs, новые поля:

• Номер сертификата certificatenum - 255 символов
• Код формы/бланка сертификата certificateform - 30 символов (должен совпадать с кодом шаблона в плагине storage/programmsbcs)
• Дата выдачи сертификата certificatedate
• Номер приказа, в соответствии с которым выдан сертификат certificateorderid

Дополнительные поля в контракт

Форма договора (шаблон) Юр. лицо (если не указано - значит договор с физ. лицом, для бесплатников указывается управление образованием и т.п.) Куратор данного ученика от работодателя (id персоны или не указан)

Справочник организаций, место работы, должность

(для коллективных договоров) Справочник организаций: Полное наименование, краткое наименование, ИНН, КПП, ОГРН, банковские реквизиты, юридический адрес (по таблице адресов), физический адрес, почтовый адрес, телефон, факс, дополнительные реквизиты, ФИО руководителя, должность руководителя, основание действия руководителя. Привязка персоны к месту работы: id персоны, id организации, основное место работы/совместитель/не известно/уволен, должность, дата приема/не известно, дата увольнения/неизвестно, рабочий телефон, добавочный номер, комментарий.

Тип итогового контроля в курсе

В справочнике programmitems добавить поле controltypeid - тип итогового контроля по данному курсу.

Разное

Автоматическое перенаправление на страницу установки всего после обновления

Каждый раз когда плагины FDO обновляются - нужно выводить на главной странице для админа кнопку "установить все". Также в интерфейсы главной страницы добавить условие: не отображать ничего до тех пор, пока не будут установлены все зависимости и обновлены все плагины, необходимые для отображения главной страницы

Список стандартных настроек

Добавить к списку стандартных настроек:

• Время для cron

Список стандартных прав доступа

Добавить к списку стандартных прав доступа:

• менять настройки планина,
• менять служебные настройки плагина

Добавить возможность задавать одновременно несколько статусов для worflow

Описание: Вместо понятия "статус" ввести понятие "тег". Станет возможность пометить объект несколькими тегами одновременно. Продумать, каким образом в связи с этим хранить статусы объектов.

Создать базовый класс для плагина workflow

Описание: В большинестве плагинов workflow приходится копировать много кода, и постоянно отлавливать ошибки, связанные с этим. Предлагается создать базовый клас для всех workflow в котором будут объявлены все функции, которые сейчас копируются. Создать в классе метод _init() (можно назвать как-то по-другому) в котором устанавливать все значения.

Например:

public function _init()
{
    $data['version'] = 2011052400;
    $data['code']    = 'cstreams';
    $data['cron']    = 900;
    $data['storage'] = 'cstreams';
    return $data;
}

Все базовые методы сделать стандартными, зависящими только от $this->type() и $this->code().

При таком подходе существенно уменьшится количество багов, ускорится разработка, а код стандартных workflow будет занимать меньше одной страницы.

Кеширование прав в storage/acl

Описание: Права в плагине acl запрашиваются при помощи сложного sql-запроса. Чтобы не производить его каждый раз предлагается добавить кеширование прав доступа. Возможно нужно будет создать отдельную таблицу.

Доработка для настроек (плагин storage/config)

Описание: В будущем настройки будут устанавливаться через графический интерфейс. Было бы очень полезно автоматически генерировать формы для всех настроек. Предлагаемые улучшения:

• Добавить возможность устанавливать зависимость одной настройки от другой (можно как настройка отдельного типа)
• Добавить в БД поле, в котором будут указываться все стандартные проверки quickform которые нужно применить к сохраняемому значению
• Добавить в интерфейс dof_storage_config_interface специальный метод, который вызывается при созранении значения настройки, и запускает собственную проверку сохраняемого значения на стороне сервера (если нужно
• Добавить кеширование настроек (чтобы не тратить ресурсы на извлечение настроек, которые запрашиваются много раз)
• Добавить стандартное свойство для настройки:уровень доступа, при котором разрешено изменение настройки

Добавить ссылку из контактов на reformal.ru

Описание: При помощи этого сервиса пользователи смогут оставлять свои комментарии и предложения по работе fdo

Для всех интерфейсных плагинов в wiki добавить раздел "сценарии тестирования"

Описание: Раздел должен состоять из таблицы со следующими полями:

• Название тестового случая
• Шаг
• Описание/действия
• ожидаемый результат

(именно в таком порядке)

Изменить отображение периодов

Описание: Отображать период в списках выбора периодов так: [Название периода]:[временные рамки периода]

Добавить возможность смены статуса договоров, подписок и проч в списках

Описание: Добавить ссылки смены статуса прямо в графу статус под статусом в котором данный объект находится в данный момент. Перед сменой статусов желательно запрашивать, уверен ли пользователь в том, что хочет сделать.

Добавить в функцию print_header (modlibs/nvg) возможность добавлять мета-данные в заголовок (реализовано)

Описание: В moodle функция print_header может добавлять в секцию <head> свои собственные данные: например у меня есть возможность добавить мета-теги, подключить собственные файлы с таблицами стилей или скриптами, а также добавить в тег body собственные атрибуты. Функция FDO таких возможностей не дает. Они необходимы нам, если мы собираемся работать с Javascript.

Разобраться с одинаковыми полями

Описание: В некоторых формах при редактировании связанных объектов (например в академических группах и подписке на курсы у ученика) появляются одинаковые поля. Одновременно задавать эти поля в обоих местах нецелесообразно, так как присутствие ученика в данной академической группе сразу их определяет.

Добавить плагин sync/import

Описание: Добавить плагин, который бы отвечал за импорт любых данных в FDO. Создать внутри плагина папку types, в которой будут храниться файлы, каждый из которых будет содержать класс с типом импорта. Создать класс dof_sync_import_base с общими базовыми функциями импорта. Все типы импорта должны будут наследоваться от него. В init-файл плагина sync/import добавить функцию import() с параметрами:

• • $type - строка, тип экспорта, который будет производиться
  • $data - массив объектов, данные которые импортируются в систему. Формат объектов определяется типом импорта.
  • $options (необязательно) - объект, содержащий набор дополнительных настроек для импорта в указанный формат.

Формат возвращаемого значения определяется типом импорта. Общие типы импорта могут находится в репозитории FDO, а специфические - создаваться отдельно.

Добавить в базовый класс workflow функцию, которая сразу устанавливает нужный статус

Описание: Это нужно, например, для того чтобы перевести контракт сразу в статус "идет обучение". Я думаю имеет смысл не писать последовательно несколько обращений к функции change() а завести одну универсальную функцию, которая будет определять, какие статусы нужно пройти и проходить их. Если на каком-то этапе возникнет ошибка - она должна останавливаться и возвращать false.

Список пользователей, для которых указана не вся информация

Описание: При создании пользователя в таблице persons из пользователя moodle не указываются те данные, которые в деканате обязательны, а в moodle она просто отсутствуют (например в таблице mdl_user отчество не хранится). Нужен скрипт, который автоматически просматривал бы список пользователей деканата (persons), и выводил тех, для которых не указаны необходимые контактные или личные данные.

Рефакторинг функций для постраничного вывода записей в интерфейсе

Описание: Добавить в класс storage_base методы

• get_listing($limitfrom, $limitnum, $conds=null, $countonly=false, $sort=null) добавление последнего параметра обусловлено тем, что нам необходимо производить выборку для каждой таблицы индивидуально
• get_select_listing($inputconds)

Какие преимущества даст осуществление этой идеи?

• Упорядочится выборка записей по страницам
• Появится возможность не присать эти методы каждый раз для нового хранилища, если нам нужен просто стандартный фильтр по записям

Конвертация todo-пометок в коде в вопросы багтрекера

Описание: Все недоделанные или не полностью реализованные места в коде мы помечаем метками @todo (я на это надеюсь). Было бы здорово найти какой-либо способ переконвертировать эти метки в задачи багтрекера и подчистить нереализованные возможности проекта.

• Какие преимущества даст осуществление этой идеи?
  • реализуем все возможности, на которые не хватало времени раньше
  • подчистим проект, сделая его стабильнее
  • получим реальную картину того сколько у нас всего не доделано.

Рефакторинг внешнего вида журнала с использованием библиотеки YUI

Описание: Переработать внешний вид страницы журнала используя библиотеку Yui. Основные элементы, которые нуждаются в переработке:

• Страница расписания урока
• Страница планирования
• Страница отображения оценок

Добавить в форму новый стандартный элемент "dof_addremove"

Описание:Элемент представляет собой двусторонний список с кнопками "добавить" и "удалить". При выделении нужного количества элементов они автоматически добавляются или удаляются из списка. Также возможна реализация этого элемента в виде виджета в классе dof_modlib_widgets.

Доработать элемент hierselect

Используя класс dof_modlib_widgets_form нужно переопределить элемент hierselect, и сделать в нем следующие правки:

• Исправить его верстку (если идет 3 и более элемента подряд - то она расползается)
• Исправить ошибку, в результате которой в hierselect нельзя в качестве значения указать просто число
• Добавить возможность отключать отдельные поля внутри элемента.
• Сделать подгрузку элементов через AJAX

Использование файла глобальных настроек блока для FDO

Описание: Если создать в папке любого блока файл config_global.html - то у этого блока появится файл настроек, который будет отображаться администратору системы в меню "модули". Возможно следует создать файл таких настроек для FDO и вынести туда часть настроек блока, либо вообще сделать такой файл настроек главным.

Графическое меню стандартных настроек FDO

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

Возможность создать новую дисциплину на основе предыдущей

Описание: Это решение подойдет для случаев, когда требуется создать углубленный курс из основного, или создать курс на основе стандарта образования. Сделать возможность создания дисциплины с готовым тематическим планированием из другой дисциплины.

Стили для стандартных элементов

Описание: создать собственную каскадную таблицу стилей для fdo. Там будут описаны стили для различных часто используемых элементов: сообщения об успешном или неуспешном завершении операций, информационных сообшений, и т. п. Это позволит стандартизировать внешний вид программ, а также более гибко работать с оформлением.

Инструмент для редактирования тематического планирования

Описание: Идея такая: создать инструмент, который позволил бы легко и быстро создавать тематическое планирование для любого предмета на основе программы из образовательного стандарта. Я представляю себе это так: двусторонний список, в котором слева находятся темы из стандарта, а справа темы нового курса (в начале это пустая колонка). Темы можно перетаскивать из левой колонки в правую. Можно менять порядок тем (drag&drop). Такой инструмент позволит легко и быстро создавать собственное тематическое планирование для любого предмета на основе образовательного стандарта.

Редактирование документации в wiki при помощи eclipse

Существуют плагины к eclipse (например вот этот), которые позволяют редактировать Википедию. Нужно узнать, будет ли этот плагин работать с нашим движком, и если нет, то какие настройки для этого потребуются.

На мой взгляд, описанные ниже преимущества стоят того, чтобы хотя бы попробовать:

• Какие преимущества даст осуществление этой идеи?
  • Нам станет проще и быстрее и удобнее редактировать документацию
  • Документация станет более структурированной (для wiki-разметки там поддерживается такая же подсветка и code-assist, как и для обычных языков программирования)
  • Больше не будем забывать документировать функцию. Написание документации в wiki станет таким же обычным и "само собой разумеющимся" процессом, как и написание phpdoc-комментариев.
  • Станет гораздо проще сопоставлять, какие функции, плагины, и классы у нас документированы, а какие - нет. Документация станет гораздо больше соответствовать коду. Проще будет проверить, для каких функций уже есть документация, а для каких - нет.
  • Возможность вставки отформатированного раскрашенного кода в wiki сразу же из буфера обмена.
  • Поддержка ссылок на документацию в коде (!!!). Как это работает: устанавливаем wiki-плагин для eclipse. Создаем новый wiki-проект. Настраиваем проект на работу с нашим wiki-движком. После этого в phpdoc-комментариях можно будет писать ссылку на документацию, кликать на ней правой кнопкой, и будет открываться соответствующая статья нашей документации. источник на английском

Добавить подсветку синтаксиса в mediawiki

Описание: поскольку наш проект посвящен программированию, было бы неплохо добавить к движку mediawiki возможность подсвечивать синтаксис php-кода. Для этого необходимо установить плагин SyntaxHighlight (описание и инструкция по установке доступны по ссылке)

• Какие преимущества даст осуществление этой идеи? Нам всем станет ощутимо проще работать с документацией по проекту.

Интерфейсный плагин, объединяющий создание всего учебного процесса

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

Например, для того чтобы создать учебный процесс (в целом), нам нужно:

1. переименовать первое, автоматически созданное подразделение из "Company" в название своего учебного заведения
2. Создать учебные программы
3. Создать дисциплины
4. Создать учебные периоды
5. Создать учебные группы
6. Зарегистрировать контракты
7. Через группы создать потоки
8. Через созданные потоки приписываем группы и учеников к дисциплинам

И так далее. На странице мы переходим от одного шага к другому, видим, что мы уже сделали, а что еще предстоит сделать.

Страницу можно реализовать как "обучающий режим", то есть - можно пройти все операции с инструкциями, а можно сразу перейти к интерфейсу, и сделать все самому.

• Какие преимущества даст осуществление этой идеи? Пользователь, никогда не использовавшему FDO станет сразу ясно с чего начать, ему не нужно будет долго разбираться в том, в какой плагин зайти сначала, а в какой потом.

Дополнительные методы для отслеживания зависимостей плагинов

Описание: число наших плагинов растет, а значит скоро нам понадобятся дополнительные инструменты для удобного отслеживания их зависимостей друг от друга. Я предлагаю добавить к интерфейсу плагина функцию get_list_dependences (можно потом подобрать более удачное название). Эта функция будет отвечать на вопрос "Какие плагины зависят от меня?". Помимо этого, в интерфейсе админки предлагаю сделать две кнопки: первая выводит список плагинов, которые зависят от этого плагина, а вторая - список плагинов от которых зависит этот плагин (т. е. обзор зависимостей в обе стороны).

• Какие преимущества даст осуществление этой идеи? станет проще отслеживать зависимости между плагинами, и станет проще избегать циклических зависимостей.

Справка по элементам интерфейса

Описание: помимо документации к самой системе необходимо внедрить справку внутрь самой системы. Я вижу это следующим образом:

1. справка внутри самой формы. В quickform есть стандартный метод, который позволяет добавлять справку к элементам формы. Эта справка будет отображаться в открывшемся новом окне. html-файлы с текстом справки должны лежать в moodledata
2. Краткая справка на каждой странице, где есть форма. Это может выглядеть примерно так: над формой помещается небольшой квадратный блок с текстом, который поясняет что можно сделать на этой странице, зачем нужна эта форма и куда мы вообще попали. Блоки с пояснениями могут размещатся на любых страницах, где требуются.
   • Должно быть 2 режима: обычный и "экспертный". В экспертном режиме работы с fdo блоки не показываются
   • Все блоки выводятся через 1 стандартный метод в плагине widgets

• Какие преимущества даст осуществление этой идеи? Пользователям станет ощутимо легче ориентироваться в самой системе, если они смогут в любой момент получить справку по любому ее элементу. Также наш проект на один маленький шаг приблизится к тому идеалу, который называется "интуитивно понятный интерфейс"
• С какими трудностями мы можем столкнуться? Все файлы справки задействуют стандартную функцию moodle, которая показывает страницу со справкой в новом окне. Все справочные файлы, вызываемые при помощи этой функции находятся в папке moodledata. Нужно будет разобраться в механизме реализации справочных файлов находящихся в moodledata. Судя по всему они хранятся где-то в отдельном месте, а только затем попадают в папку moodledata, которая создается автоматически в процессе установки moodle.

Презентация по структуре freedeansoffice 2.х

Описание: создать презентацию или flash-ролик по структуре деканата: как он работает, как он соотносится с учебным процессом, какие преимущества он дает.

• Какие преимущества даст осуществление этой идеи? Людям далеким от программирования станет понятнее что это за проект, зачем он нужен, и почему его нужно установить.

Использование библиотеки YUI

Описание: в список стандартных библиотек moodle включена библиотека "Yahoo User Interface" второй версии. Она позволяет использовать Javascript и CSS, а также использовать технологию AJAX. Совместима со всеми браузерами. Имеет весьма подробную документацию на английском языке, и примеры использования.

• Какие преимущества даст осуществление этой идеи? Использование этой библиотеки значительно поможет нам улучшить внешний вид проекта, а также использовать технологию AJAX, которая ранее была не доступна.
• С какими трудностями мы можем столкнуться? Для того чтобы использовать эту библиотеку нужен уровень понимания принципов действия Javascript/CSS выше начального.

Добавление стандартного поля dof в класс dof_modlib_widgets_form

Описание: В используемый вариант htmlQuickForm было бы полезно добавить поле dof которое сейчас добавляется вручную (через конструктор, в массиве _customdata). Это можно автоматизировать, если на шаге наследования формы от moodleQuickForm добавить в форму поле dof, куда записать объект dof_control.

Старые формы не нужно будет переделывать, они продолжат работать как и раньше.

• Какие преимущества даст осуществление этой идеи? Упростится и стандартизируется процесс разработки форм, сократится количество кода.

Дополнительная функция извлечения данных для класса storage

Описание: При получении данных из хранилища часто возникает необходимость получить несколько записей по двум или трем полям. Сейчас в storage есть три основные функции:

1. get_list() - получить массив записей по одному полю
2. get_filter() - получить только одну запись по трем полям
3. get_list_select() - получить массив записей, используя собственный sql-запрос

К этим функциям необходимо добавить еще одну, которая позволяла бы получить массив записей по нескольким полям.

• Какие преимущества даст осуществление этой идеи? Легче будет извлекать данные из таблиц, не нужно будет писать собственный sql-запрос каждый раз, когда нужно получить массив записей по нескольким полям.

Сохранение времени в БД

По стандарту у нас в БД дата хранится всегда на полдень. Сейчас функция, которая переводит текущую метку времени в метку времени полудня лежит в /dof/im/journal/lib.php - dof_im_journal_get_date($time). Может переложить ее куда-то поближе к ядру, чтобы удобно было из любого плагина дергать.

Поэтапное заполнение нового договора

Надо страницу нового договора (im/sel/contracts/new.php) разделить на несколько. На одной странице заполнять информацию об ученике. На другой - о представителе. Так как набор заполняемых полей для ученика зависит от наличия представителя.

Добавление дополнительных типов проверок и элементов в QuickForm

Описание: Во время написания статьи про QuickForm я наткнулся на возможность назначать собственные виды проверок данных на стороне клиента, и собственные типы html-элементов. Возможно это может пригодиться нам для работы над интерфейсными плагинами - часто повторяющиеся элементы можно создать один раз, чтобы потом много раз не писать их заново. Код всего этого можно поместить в dof_modlib_widgets form.

Также можно добавить новые интерактивные элементы в форму. Также имеет значение то, что по умолчанию в quickForm отсутствует проверка значений с русскими буквами на стороне клиента - ее следовало бы добавить.

• Какие преимущества даст осуществление этой идеи? появится возможность проверять русскоязычные значения на стороне клиента, ускорится разработка интерфейсов.
• Каких ресурсов это потребует? Пока неизвестно.
• С какими трудностями мы можем столкнуться? Надо будет по примерам из Moodle разобраться в том, как происходит регистрация элементов и проверок в форме.

Построение графиков и диаграмм в OpenOffice Calc при помощи плагина templater

Краткое описание: Используя разметку шаблонизатора Sigma так разметить файл электронной таблицы формата ods, чтобы созданный в нем график каждый раз строился на основе экспортируемых данных.

• Какие преимущества даст осуществление этой идеи: Можно будет встраивать различные графики и диаграммы в отчеты, что даст дополнительные преимущества плагину templater.
• Каких ресурсов это потребует: Пока неизвестно.
• С какими трудностями мы можем столкнуться: Надо будет разобраться, как устроено XML-отображение графиков в openOffice.

Дополнительное описание для плагинов

Краткое описание: В меню установки плагинов, при просмотре списка должно выводиться не только название плагина, но и его небольшое описание, которое говорит о том, для чего нужен этот плагин, и какие функции он выполняет.

Там же выводить, какие плагины нужны для его установки (если есть зависимости), и отмечать, установлены они уже или нет.

После краткого описания плагина давать ссылку на наш wiki, где этот плагин описан полностью.

Описание изначально скрыто, и показывается по щелчку на ссылке "показать".

Сортировать плагины следующим образом: сначала установленные, затем не установленные.

Также в будущем необходимо будет разделить плагины на группы: одни плагины необходимы для базовой функциональности системы, другие нужны для расширения ее возможностей. Будет "базовая комплектация", работающая "из коробки" и дополнительные плагины.

• Какие преимущества даст осуществление этой идеи? Неподготовленным пользователям и администраторам не знакомым с нашей системой будет проще в ней ориентироваться. Проще будет определять, какие плагины нужны, а какие нет.
• Каких ресурсов это потребует? Приблизительно часов 5-6, для того чтобы добавить новые методы в базовый класс, и протестировать их работу.
• С какими трудностями мы можем столкнуться? На создание и описание каждого нового плагина будет уходить несколько больше времени.

Система полномочий на основе доверенностей с фильтрами

Краткое описание:

• Какие преимущества даст осуществление этой идеи?
• Каких ресурсов это потребует?
• С какими трудностями мы можем столкнуться?

Специальный режим для "тяжелых" процессов:

Краткое описание:Использовать специальный код для выполнения тяжелых и трудоемких процессов.

   @set_time_limit(0);
   @raise_memory_limit("512M");
   if (function_exists('apache_child_terminate'))
   {
       // Перезапустить процесс после исполнения
       // на случай утечек памяти
       @apache_child_terminate();
   }
   if (function_exists('ignore_user_abort'))
   {
       //не прерывать выполнение скрипта при отсоединении клиента
       ignore_user_abort();
   }

• Какие приемущества это дает?
• Каких ресурсов это потребует?
• С какими трудностями мы можем столкнутся?

При записи в языковые файлы пользоваться константами:

Выглядеть это должно подобным образом:

   define('student', 'ученик');
   $string['student'] = student;
   $string['student_list'] = 'Список '.student.'ов';

В результате, для переноса такой записи в основной языковой файл из Susi нужно будет просто поменять значение константы student на 'студент'

Идеи для рефакторинга

В этом разделе собраны все идеи, которые следует реализовать при рефакторинге системы

Реорганизация структуры плагинов sync

Предлагается полностью изменить структуру плагинов sync. Располагать плагины в зависимости от того, с какой системой они будут синхронизироваться. Внутри папки sync создать столько папок, сколько систем доступно для синхронизации, и в эти папки класть плагины sync. В базовый класс плагина sync добавить свойство "externalsystem" в которое записывать название системы, с которой происходит синхронизация. Пример

/sync/moodle/persons
/sync/moodle/programmitems
/sync/naumen/persons
/sync/naumen/programmitems

Список условий для смены статуса

При переходе с системы статусов на систему тегов необходим стандартный метод в базовом классе workflow, который возвращает список условий, которые необходимо выполнить, прежде чем изменить статус. Метод, который отвечает на вопрос "что и в каких плагинах должно произойти, чтобы стало можно изменить статус?". Дополнительно к этому помечать: обратима ли смена статуса. При попытки сменить статус на конечный выдавать сообщение "Эта смена статуса является необратимой. Продолжить?"

Доработать элемент dof_duration

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

Добавить в базовый плагин im функции преобразования значений БД в текст

Описание: В стандартном плагине интерфейса нужно предусмотреть возможность вызова стандартных функция преобразования значений в текст. Предлагается реализовать функции: 1) функция преобразования значений 1 и 0 в "да" и "нет" 2) Функция автоматического преобразования статуса в базе в статус текстом. Аргументы:

• статус
• workflow который за эти статусы отвечает

Полный рефакторинг модуля ama

Описание: Нужно полностью переписать этот модуль, изменить логику его работы таким образом, чтобы при обращении к нему не возникало никаких непредвиденных ситуаций, вроде создания новых пустых курсов или пользователей. Самое главное изменение логики:

• Все объекты создаются функцией create($obj) обновляются функцией update($obj) и удаляются функцией delete($id), и получаются функцией get($id)
• Конструктор класса просто создает объект с данными и никогда не производит никаких манипуляций с базой данных (никакого скрытого создания или удаления объектов и т. п.). Должна быть возможность создать объект, не создавая при этом запись в БД.
• При любых ошибках модуль никогда не обращается к функции print_error. Он только кидает исключения, и делает это только в режиме отладки. В обычном режиме ошибки просто записываются в лог