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

Ядро 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, пока всё необходимое не будет установлено. При автоматической массовой установки плагинов, система будет пропускать такой плагин и ставить его в конец очереди установки, пока не установятся все необходимые плагины.