GSP против контроллера в Grails - PullRequest
0 голосов
/ 19 января 2012

У меня есть некоторый опыт поддержки приложений Grails; Теперь создаем приложение «Управление задачами» в качестве упражнения.

По-видимому, существует дихотомия представления Страницы Groovy Server против Действия контроллера , которые визуализируют представление, о чем свидетельствует этот фрагмент из примера URLMappings.groovy:

static mappings = {

    // ..

    "/" (view:'/index')
    "/login/$action?" (controller: 'login')
    "/logout/$action?" (controller: 'logout')

    "500" (view:'/error')
}

где URL-адреса пользователя должны быть сопоставлены либо с представлениями (GSP), либо с контроллерами, отображающими представление, например ::

class LoginController {

    /**
     * Show the login page. 
     */
    def auth = {

        // .. auth logic

        String view = 'auth'
        String postUrl = "${request.contextPath}${config.apf.filterProcessesUrl}"
        render view: view, model: [postUrl: postUrl, rememberMeParameter: config.rememberMe.parameter]
    }

}

С точки зрения дизайна, как выбрать метод для использования? Когда я создаю представления с GSP / taglibs, как обычные страницы сервера, выводящие HTML, и когда я сопоставляю URL с контроллером, который рендерит через делегат GSP? Могу ли я объединить оба подхода? Разве я здесь упростил варианты?

Ответы [ 2 ]

3 голосов
/ 19 января 2012

Чтобы добавить к словам hvgotcodes, связанным с вашим вопросом, единственный раз, когда вы хотите отобразить непосредственно на представление GSP, это когда это представление фактически является "статическим".

Под статическим я имею в виду, чтоон не полагается на базу данных или какие-либо реальные расчеты для визуализации представления.Он по-прежнему может быть динамичным, поскольку он использует библиотеки тегов для работы с общими элементами и такие вещи, как текст «Welcome user » вверху страниц.

Как только вы захотитедля работы с пользовательским вводом, поиска информации в базе данных, управления более сложными URL-адресами или включения вычислений вы должны использовать контроллер.

Конечная цель заключается в том, чтобы GSP содержали только визуальную информацию и информацию о компоновке.как случайный статический блок текста.Но вы всегда должны избегать смешивания какой-либо логики с GSP, потому что это загромождает код, и всегда приводит к головным болям обслуживания в дальнейшем.


Редактирование в отношении библиотек тегов:

Как я уже писал ниже:

Библиотеки тегов предназначены для любой логики, связанной с представлением, например, циклический переход по элементам или переключение видимости чего-либо.Всякий раз, когда у вас возникает желание поместить код непосредственно в ваш GSP, его, вероятно, следует поместить в библиотеку тегов.Конечно, для одноразовых исключений всегда есть исключения.

Итак, если в вашем представлении есть логический код, то конкретно относится к визуальному или макетному контенту, который должен бытьположить в библиотеку тегов.Хорошим примером является тег <sec:ifLoggedIn> из Spring Security Core, который можно использовать для переключения видимости элемента, если пользователь вошел в систему. Это гораздо лучше, чем писать его вручную, например:

<sec:ifLoggedIn>blah blah</sec:ifLoggedIn>
<g:if test="${session.user?.loggedIn}">blah blah</g:if>

Потому что это делает цель более понятной (по названию), а также абстрагирует логику, поэтому, если вам позже потребуется изменить способ работы, вам нужно будет изменить его только в одном месте.


tl; dr:

  • GSP - упрощенный «статический» контент
  • Теги - многократно используемые динамические компоненты, специально предназначенные для визуального или макетного контента
  • Контроллеры / GSP - динамический контент
1 голос
/ 19 января 2012

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

Материал отображения URL предназначен для того, чтобы, если вы хотите нарушить соглашение Grails для URL-адресов, которое ортогонально тому, как должны работать загрузка данных и отображение данных (предполагается).

Единственное время (ИМХО), в котором есть дихотомия, - это когда разработчики в коде проекта несогласованно функционируют; то есть, безусловно, возможно создать видимость дихотомии.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...