2009-11-15 3 views
2

Я ищу способ изменить/изменить существующее закрытие. Однако я не хочу его перезаписывать; вместо этого я хотел бы улучшить его.Groovy/Grails: улучшите статическое закрытие

Вот краткий пример. Предположим, у нас есть адресный объект:

class Address { 
    String street 
    String city 
    String state 
    String zipCode 

    static constraints = { 
     street(nullable:true) 
     city(blank:false) 
     state(size:2..2) 
    } 
} 

Это был бы хороший пример, поскольку он также является действительным объектом домена Grails. То, что я ищу, чтобы сделать, это добавить еще одно ограничение, во время выполнения/динамически класса Адрес:

class Address { 
    String street 
    String city 
    String state 
    String zipCode 

    static constraints = { 
     street(nullable: true) 
     city(blank: false) 
     state(size: 2..2) 
     zipCode(size: 5..6) 
    } 
} 

Обратите внимание, что новый zipCode ограничение? Я понимаю, что я могу скрыть все ограничения, переставив его через metaClass; однако цель здесь не в том, чтобы повредить никому в процессе, поэтому я просто хочу, чтобы добавить к существующему закрытию.

+0

Разве вы не говорите: «Моя, какая красивая структура!» дополнять структуру? Или вам нужно использовать более сложные описания? –

+0

Да, просто попробовал это. И хотя закрытие было очень довольным, у него все еще отсутствовал 'zipCode' ... – tolitius

ответ

2

Думаю, вам может быть не повезло. Из того, что я могу сказать, разработчики Grails не хотят, чтобы вы изменяли ограничения во время выполнения. Ограничения сохраняются в

org.codehaus.groovy.grails.commons.DefaultGrailsDomainClass 

где сами ограничения сохраняются в частную карте, с единственным аксессором

public Map getConstrainedProperties() 
{ 
     return Collections.unmodifiableMap(this.constraints); 
} 

Ограничения закрытие обрабатывается org.codehaus.groovy.grails.validation.ConstrainedPropertyBuilder.

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

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

Update

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

В 1.2 Grails добавлены общие ограничения. Интересно, можете ли вы создать ограничение общего доступа zipCode, каким-то образом изменить его, а затем вызвать обновление.

+0

Я согласен с тем, что ограничения домена не должны быть модифицируемыми после запуска приложения, однако для целей плагина, я думаю, они должны быть открытыми. «общие ограничения» потребуют от пользователя вручную * ввести * свойство в статический блок. в любом случае спасибо за рытье в – tolitius

+0

Нашли эту тему, которая может быть актуальна здесь. http://old.nabble.com/Is-it-possible-to-inject-constraints-dynamically-on-domain-classes--td24489941.html –

3

Вы действительно можете изменить ограничения во время выполнения.

ConstrainedProperty constrainedProperty = Address.constraints.zipCode 
constrainedProperty.setSize(5..6) 
0

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

Смежные вопросы