2010-07-03 7 views

Répondre

4

Habituellement, je redirige les gestionnaires de code d'erreur vers un contrôleur afin que je puisse effectuer une journalisation ou autre avant de rendre la vue. Vous pouvez l'utiliser ici aussi:

class UrlMappings { 

    static mappings = { 

     "/searchable/$action?"(controller: "errors", action: "urlMapping") 

     "/$controller/$action?/$id?" { } 

     "/"(view:"/index") 

     "403"(controller: "errors", action: "accessDenied") 
     "404"(controller: "errors", action: "notFound") 
     "405"(controller: "errors", action: "notAllowed") 
     "500"(view: '/error') 
    } 
} 

où ErrorsController ressemble à quelque chose comme ceci:

class ErrorsController { 

    def accessDenied = {} 

    def notFound = { 
     log.debug "could not find $request.forwardURI" 
    } 

    def notAllowed = {} 

    def urlMapping = { 
     log.warn "unexpected call to URL-Mapped $request.forwardURI" 
     render view: 'notFound' 
    } 
} 

et vous aurez besoin de créer accessDenied.gsp, notFound.gsp et notAllowed.gsp dans grails- app/errors

En envoyant un contrôleur 'caché' à son mappage personnalisé, vous pouvez vous connecter à un accès inattendu, mais toujours rendre la page 404 pour masquer son existence.

+0

C'est une bonne idée, alors je peux le faire ressembler à n'importe quelle autre ressource introuvable erreur. J'aime ça! J'avais créé un /views/searchable/index.gsp pour écraser celui inclus avec le plugin, mais je vais juste m'en débarrasser et le faire de cette façon. Merci! –

+0

@Burt - est-il possible de simplement désactiver/supprimer l'UrlMapping au démarrage? Ce serait une solution beaucoup plus élégante. –

+0

Vous pourriez probablement l'enlever, mais je doute que ce soit une solution simple. On dirait un bon candidat pour une demande de fonctionnalité. Il pourrait probablement être implémenté lorsque nous faisons des espaces de noms de contrôleur (provisoirement v2.2). –