Ответ 1
Вы можете использовать
class B extends A {
static constraints = {
importFrom A
//B stuff
}
}
как состояния в http://grails.org/doc/latest/ref/Constraints/Usage.html
Вот что я хотел бы сделать:
class A {
String string
static constraints = {
string(maxSize:100)
}
}
class B extends A {
static constraints = {
string(url:true)
}
}
Таким образом, класс A должен иметь некоторые ограничения, а B должен иметь те же плюс дополнительные ограничения для одного и того же свойства.
Я не мог заставить это работать, и я могу представить, что он столкнулся бы с концепцией Table-per-Hierarchy.
Итак, я попытался обойти эту проблему, представив объект Command с ограничениями класса B, которые могут быть проверены в конструкторе класса B. Однако кажется, что объекты Command могут использоваться только в контроллерах (граф говорит, что существует для него нет метода .validate().
Итак, мой вопрос: что является самым изящным способом решения этой проблемы с использованием ограничений Grails (не повторное внедрение проверки вручную)? Может быть...
Изменить:. Мне было бы хорошо определить все ограничения в дочерних классах, повторяя ограничения родительского класса или вообще не имеющие ограничений в родительском классе. Но решение должно работать для нескольких дочерних классов (с разными ограничениями) одного и того же родительского класса.
Вы можете использовать
class B extends A {
static constraints = {
importFrom A
//B stuff
}
}
как состояния в http://grails.org/doc/latest/ref/Constraints/Usage.html
Как это было в 2.x:
Поскольку ограничения являются закрытием, выполняемым некоторыми ConstraintsBuilder, я бы попробовал называть его из B, например
class B extends A {
static constraints = {
url(unique: true)
A.constraints.delegate = delegate # thanks Artefacto
A.constraints()
}
}
В принципе, я не вижу, как это можно сделать.
Конструктивно, класс домена фактически отображает структуру таблицы базы данных. Ограничения будут фактически создавать ограничения DB. Поэтому вы пытаетесь создать несколько объектов, которые будут генерировать различные ограничения в одной таблице.
Я думаю, что лучшим подходом было бы создание одного объекта домена, который имеет простейшее подмножество ограничений, а затем использовать разные объекты команд для точной настройки точных ограничений, которые вы хотите передать в домен.
Вы также можете использовать валидатор: в ограничениях для тонкой настройки разных ограничений для разных типов объектов (что-то вроде столбца типов в домене и на основе разных типов выполняет другую проверку).
Вам нужно переопределить ограничения суперкласса, потому что статические clojure (статические свойства и статические методы не наследуются дочерними классами), поэтому он не отображается GORM.
Приветствия.