2012-04-10 23 views

Respuesta

18

Lo que hace setResponsePage depende de un par de factores: cuántas veces llama a setResponsePage, qué variante de setResponsePage llama y qué estrategia de representación utiliza.

Puede llamar al setResponsePage muchas veces durante una solicitud. Wicket usa el último para trabajar.

Hay dos variantes de setResponsePage: con una instancia Page y con una clase Page y PageParameters. Este último envía un redireccionamiento a una URL marcable para el navegador. El antiguo testamento, dependiendo de la render strategy, ya sea:

  • ONE_PASS_RENDER
    • representar la página directamente en el navegador
  • REDIRECT_TO_BUFFER
    • representar la página a un búfer, envía una redirección al navegador (que luego recupera el marcado almacenado y procesado) o
  • REDIRECT_TO_RENDER
    • enviar una redirección al navegador, que a su vez envía una solicitud para representar la página

Así que la primera opción es el envío, la segunda opción es el envío seguido de una redirección, y la tercera opción sería redirigir en términos de servlet.

+0

@Martin Dashorst: ¿el navegador ve un 302 en REDIRECT_TO_BUFFER? – bert

+1

sólo trató con mi proyecto: Solicitud URL: http: // localhost: 8080/som/app/home 14-2.ILinkListener-menu-Personalidades Solicitud Método: Obtener código Estado: Encontrado 302 Así sí, Wicket envía un 302 en ese caso. –

+0

@Martin Dashorst: gracias, esto realmente explica por qué tenemos un 302 que lleva más tiempo que el 2, debido al buffer. Genial, otro misterio resuelto;) – bert

1

setResponsePage (PageName.class) redirigirá el navegador al PageName que necesita ir. Asegúrate de que ya hayas montado tu Page.class en una ruta determinada. Por ejemplo, en su método de inicio de aplicación, puede montar así mountPage ("/ home.html", WelcomePage.class); luego en alguna otra página, cuando necesite ir a la página de inicio, simplemente llame al setResponsePage (WelcomePage.class);

Cuestiones relacionadas