13 521
правка
Изменения
м
Нет описания правки
В Bugzilla половина кода в шаблонах, половина на основе полу-ORM’а Bugzilla::Object. Большая часть — говнокод. С одной стороны — ORM бы туда, было бы классно, НО! ORM мало, и нужен не он! Все (существующие) ORM-движки — это просто объектный интерфейс к базе данных. А нужно некое объектное ядро, которое бы позволяло создавать свои объекты, с полями различных типов, в том числе и ссылающимися на другие такие же объекты, с возможностью приписывания специальных особенностей полю, с общим механизмом хранения истории и с автоматическим базовым CRUD-интерфейсом.
На самом деле, выше описан почти что [http://roundup.sourceforge.net/ Roundup], за теми исключениями, что он не умеет зависимые селекты (раз) и :)
== Идеи по созданию объектного ядра ==
</graph>
Связь «многие ко многим» багов с ключевыми словами можно разбить на две «один ко многим»: <graph>digraph G { Тег -> "Тег бага"(тег → Баг -> "Тег тег бага"←}</graph>баг).
Причём, понятное дело, если баг принадлежит к некоторому продукту (через компонент), то и его версия, milestone, agreement должны принадлежать к тому же продукту. Сейчас в Bugzilla это реализуется так — для каждой сущности, связанной с багом, в баге есть «поле», а для ограничения значений полей поля делаются «зависимыми» от других полей. Из-за этого там куча костылей и, по сути, повесить зависимость на отличное от поля «продукт» поле невозможно.
; Скрытие/показ полей бага в зависимости друг от друга: Сейчас в Bugzilla это реализовано отдельно от функционала контроля значений — по сути, скрываться выпадающее поле может в зависимости от одного поля, а набор значений может при этом меняться в зависимости от другого. А на самом деле '''''это неправильно'''''! Что за бред — поле скрыто, но при этом есть варианты, которые можно выбрать? Или наоборот — поле доступно, но из вариантов — только пустое значение. Не подходит. Соответственно, контроль показа поля в том виде, в котором он есть в Bugzilla сейчас, актуален только для полей других типов — строковых и так далее.
; Email-уведомления об изменениях: С ними более-менее всё понятно. По сути, они всегда привязываются к какому-либо полю какого-либо объекта общей структуры, ссылающемуся на пользователя/пользователей (например, Assignee и CC бага) — это со стороны ссылок на пользователей. Вторая сторона — событие, но единственно возможные события — изменение поля или создание новой сущности.
На самом деле, нужно понять, вообще схема, реализованная в самой багзилле, чем плоха?
* Значения кастом полей в таблице багов хранятся не ссылками по ID, а по именам, что создаёт геморрой для зависимых полей, так как чтобы точно идентифицировать значение, приходится брать ещё и значение поля, от которого оно зависит.
* «Поле» (селект и мультиселект) совмещено с объектом, соответственно, не добавишь дополнительных атрибутов объекту.
* Для выпадающих списков есть как «контроль значений», так и «контроль видимости поля», что в корне неверно (см. выше).
* По факту, ни от чего, кроме продукта, зависимым значение не сделаешь.
* История хранится только для багов, но не для остальных объектов.
* Поля не генерятся автоматически, а ручками вписываются в шаблоны.
== Текущее состояние ==
Базовые поля (то, чего не быть логически не может):
* Объект, баг, пользователь, группа, комментарий к багу.
* Продукт имеет специальный смысл — разграничение прав. Поэтому он тоже обязателен.