2009-12-07 3 views
9

Просто интересно, что такое «лучшая практика» при добавлении пар ключ-значение конфигурации в ваше приложение grails.Файлы конфигурации Grails: лучшая практика

Следует ли добавить в Config.groovy или создать новые файлы.

Я попытался создать новый файл конфигурации (Company.groovy), но не смог получить доступ к реквизитам конфигурации из своего приложения. Однако, когда я вставляю свои свойства в Config.groovy, у меня есть к ним доступ ... Это работает отлично, но я не хочу, чтобы Config.groovy стал слишком большим. Еще одна проблема подняла голову. Во время выполнения тестов интеграции я обнаружил, что «test» env не имел доступа к моим новым свойствам конфигурации (значения были равны нулю).

Я должен делать что-то принципиально неправильно. Любой совет будет принят во внимание.

Спасибо, D

+3

Это действительно хороший вопрос, не аргументированные ответов и верхний ответ предоставил мне хорошую информацию, которая ответила на вопрос, который я имел о рефакторинге сложного Config.groovy файла. Поскольку приложения Grails увеличиваются к году, этот вопрос более уместен для большего числа людей. –

+0

Это полезно: http://stackoverflow.com/questions/6602620/grails-config-include-another-config-file – osa

+0

Это также полезно: http://stackoverflow.com/questions/13648194/grails- external-configuration-cant-access-to-external-variable-getting-always – osa

ответ

8

Я не уверен, что есть конкретные лучшие практики. Я могу рассказать вам плагины, которые просто добавляют несколько вариантов, как правило, повторно используют Config.groovy, но те, которые требуют более сложной конфигурации (например, Nimble), обычно имеют свой собственный файл, который можно разделить. Таким образом, это действительно зависит от ваших конкретных потребностей и объема конфигурации, которую вы хотите добавить.

Если вы изучите Config.groovy, вы увидите в нескольких верхних строках (воспроизведенных здесь), что вы можете указать, где Grails будет искать файлы конфигурации. Он автоматически может объединять свойства и файлы .groovy для вас.

// locations to search for config files that get merged into the main config 
// config files can either be Java properties files or ConfigSlurper scripts 

// grails.config.locations = [ "classpath:${appName}-config.properties", 
//        "classpath:${appName}-config.groovy", 
//        "file:${userHome}/.grails/${appName}-config.properties", 
//        "file:${userHome}/.grails/${appName}-config.groovy"] 

This section in the docs описывает варианты для вас.

+0

Спасибо, Жан! Также я нашел удобный пост для насмешливой конфигурации для интеграционных тестов сервисов (http://mrhaki.blogspot.com/2009/12/grails-goodness-mocking-configuration.html) – Derek

7

Чтобы добавить ответ выше, если вы назовете свой файл MySampleConfig.groovy (просто закончите имя файла с помощью Config.groovy), его следует добавить в контекст grailsApplication, чтобы вы могли ссылаться на следующее:

sample{ 
     first{ 
      name = "Italy" 
     } 
     second{ 
      name = "Spain" 
     } 
} 

как

grailsApplication.config.sample["first"].name 
grailsApplication.config.sample["second"].name 

модули Вилки я считаю себя немного по-другому и с помощью ConfigSlurper или подобного не требуется (я очень открыт для коррекции на этом).

def config = new ConfigSlurper().parse(new File('grails-app/conf/MySampleConfig.groovy').toURL()) 
println config.sample['first'].name 
println config.sample['second'].name 
+0

grailsApplication? ... у меня возникают проблемы с этим – Rafael

+0

@Rafael - 'grailsApplication' должен быть доступен для артефактов grails через инъекции – tylerwal

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