Формат по умолчанию для withFormat в Grails 3.x

#grails #grails-3.3

#граали #grails-3.3

Вопрос:

В Grails это может быть использовано для согласования содержимого, что особенно полезно для реализации API:

 withFormat {
    xml { ... some code that renders XML }
    json { ... some code that renders JSON }
}

Теперь, если мне нужен формат по умолчанию, скажем, JSON, «… некоторый код, который отображает JSON», должен выполняться дважды, один раз для параметра JSON и один раз для параметра «*», то есть AFAIK «любой другой соответствующий формат», который является способом указать формат по умолчанию, например:

 withFormat {
    xml { ... some code that renders XML }
    json { ... some code that renders JSON }
    "*" { ... some code that renders JSON }
}

Мои вопросы:

Это правильный способ указать формат по умолчанию как JSON?
Есть ли способ не повторять один и тот же код для двух вариантов? (Я имею в виду что-то вроде: json, «*» { …}

Ответ №1:

Вместо этого…

 withFormat {
    xml { ... some code that renders XML }
    json { ... some code that renders JSON }
    "*" { ... some code that renders JSON }
}

Используйте это:

 withFormat {
    xml { ... some code that renders XML }
    "*" { ... some code that renders JSON }
}

1. Это один из тех моментов, когда я понимаю, насколько я был слеп, думая, что мне нужно явно указывать каждый формат, а затем «остальное», так просто … спасибо, Джефф, ты всегда здесь очень помогаешь.

Ответ №2:

Единственная проблема с этим заключается в том, что это сильно избыточно и должно выполняться в КАЖДОМ МЕТОДЕ КОНТРОЛЛЕРА. Предложил бы перенести эту функциональность в HandlerInterceptor или использовать что-то вроде плагина Beapi API Framework

1. Спасибо за комментарий, но не отвечает на вопрос.

2. Вы не пробовали фреймворк. Он автоматически форматирует на основе запроса API. Если вы вызываете JSON, он автоматически форматируется для JSON и т. Д. Вам не нужно беспокоиться О ИЗБЫТОЧНОМ КОДИРОВАНИИ ЭТОГО В КАЖДОМ ОТДЕЛЬНОМ МЕТОДЕ КОНТРОЛЛЕРА. Хотя я уверен, что в OCI есть несколько разработчиков Grails, которые считают, что плохое ООП — это хорошая практика.

3. Вопрос заключается в том, как это сделать в Grails, что, я думаю, возможно, поскольку Джефф правильно ответил на него, поэтому фреймворк или плагин не требуются. В любом случае, в ответе не указано, КАК сделать то, что было задано, поэтому этот ответ неверен и не имеет контекста.

4. Функциональность, которую вы используете для этого, ЯВЛЯЕТСЯ плагином. Grails 3 отделяет функциональность от плагинов. Так что да… вы используете плагин, на самом деле несколько. Посмотрите на свой файл build.gradle. Фреймворк Beapi просто запутывает, упрощает и автоматизирует, поэтому подобные ошибки не возникают. И Джефф ответил в меру своих возможностей, используя свои знания API; это не делает его лучшим ответом. Просто ДОСТУПНЫЙ ответ.

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