Разработка:Ядро

Ядро Free Dean's Office

Эта страница содержит документацию по ядру FDO

Реализация

Описание файлов ядра, их назначение и технические детали

Версии и интерфейсы

Для корректной проверки зависимостей, в FDO обозначаются версии ядра, версии интерфейса ядра, версии интерфейса плагинов, версии плагинов.

Версии ядра

Выпущенные версии Получить версию текущего ядра можно вызовами $DOF->version() и $DOF_version_text().

Первый метод возвращает версию в виде простого, положительного целого числа. В качестве числа используется дата релиза (год, месяц, день, доп. код 00). Чем больше число - тем более новая версия ядра. Используется для автоматического сравнения версий и в механизме обновлений. Например: 2011112100

Второй метод возвращает текстовое обозначение версии, для удобства чтения человеком. Программно никак не обрабатывается. Например: 2.3.2 Чтение версий

• 2.x.x - первый разряд обозначает версию платформы. Существовал Электронный деканат версии 1.x.x, который имел совершенно другую архитектуру и функционал. Первый разряд версии меняется очень редко, при революционных изменениях в системе.
• 2.3.x - второй разряд обозначает существенные изменения в архитектуре или добавление значительного функционала. Например: версия 2.0.x была "голой" платформой для разработки модулей, версия 2.1.x позволяла хранить и управлять информацию об участниках учебного процесса, версия 2.2 содержала полноценную информационную модель учебного процесса (с группами, учебными программами, текущими и итоговыми оценками, журналами, зачетными книжками и дневниками и т.д.), версия 2.3 включала новые механизмы управления правами доступа и распределения объектов по подразделениями, в версии 2.4 платформа переведена с Moodle 1.9 на Moodle 2.2
• 2.3.1 - последний разряд обозначает выпуск релизов с добавленным пользовательским функционалом (обычно - несколько раз в год).
• Суффиксы версий, используемые в процессе выпуска
  • 2.3.2dev5015 - версия для разработчиков с номером ревизии в SVN 5015, выпущенная в процессе работы над версией 2.3.2. Обычно, такая версия выпускается в конце итерации (раз в неделю), доступна только через SVN.
  • 2.3.1beta1, 2.3.2beta2 - бета-версии для публичного тестирования
  • 2.3.1rc1, 2.3.2rc2 - релиз-кандидаты, которые становятся релизом, если в них не найдено существенных недостатков.

Версии интерфейсов ядра и плагинов

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

Версия интерфейса ядра получается методом $DOF->compat() - выражает способность ядра обеспечивать потребности плагинов в API ядра. Например: aquarium_abc Изменение версий:

• aquarium_a
• aquarium_ab - в интерфейс добавлены новые методы или изменены старые таким образом, что все плагины, которые были расчитаны на aquarium_a могут продолжать пользоваться существующим API (обеспечена односторонняя вертикальная совместимость).
• aquarium_abc - ядром могут пользоваться плагины, расчитанные на aquarium_abc, aquarium_ab, aquarium_a
• aquarium_ac - значительные изменения в API ядра. Для плагинов aquarium_ab и aquarium_abc совместимость потеряна, но плагины aquarium_a по-прежнему могут пользоваться методами ядра, которые в них использовались
• aquarium_b - полная потеря совместимости со всеми предыдущими плагинами

Ядро тоже пользуется методами плагинов и накладывает на них свои требования (которые могут отличаться от требований плагинов к ядру). Они строятся аналогично, но выражаются в требованиях ядра к плагинам. Как правило, речь идёт о методах, объявляемых в init.php. Получить список требований текущего ядра к интерфейсам плагинов можно получить методом $DOF->plugin_compat($type).

Версии плагинов

Каждый плагин должен содержать методы, возвращающие информацию о его версии:

• $plugin->version() - версия плагина, в виде простого целого числа, аналогично целочисленной версии ядра. Используется в механизме апгрейдов, поэтому важно, чтобы версии всегда только возрастали.
• $plugin->compat_dof() возвращает версию интерфейса ядра и сравнивается с $DOF->compat() для определения совместимости. Плагин считается совместимым, если начало строки $DOF->compat() полностью повторяет $plugin->compat_dof(). $DOF->compat() может быть длиннее $plugin->compat_dof(), но не наоборот.
• $plugin->compat() - возвращает версию API, которую реализует сам плагин и сравнивается с $DOF->plugin_compat($type). Плагин считается совместимым, если начало строки $DOF->plugin_compat($type) полностью повторяет $plugin->compat(). $plugin->compat() может быть длиннее $DOF->plugin_compat($type), но не наоборот.
• $plugin->need_plugins() - возвращает массив со списком плагинов, необходимых для работы текущего плагина (зависимостей). Для каждого плагина можно указать версию, тогда совместимой будет считаться указанная версия или новее.
• $plugin->is_setup_possible() - необязательный метод для проверки зависимостей на момент установки. Если он объявлен, установка будет выполнена только если он возвращает true. Используется для исключения кольцевых зависимостей: если наш плагин в процессе установки использует другие плагины и необходимо, чтобы они были установлены раньше него, is_setup_possible() должен возвращать false, пока всё необходимое не будет установлено. При автоматической массовой установки плагинов, система будет пропускать такой плагин и ставить его в конец очереди установки, пока не установятся все необходимые плагины.