La gestión de URLs en Wicket es flexible, y en ocasiones, el mismo tipo de petición puede ser codificada de múltiples maneras. Por ejemplo, dependiendo de la configuración, los fragmentos de URL foo=bar, foo/bar y x773s=09is7 pueden significar lo mismo. En el primer paso del manejo de una petición, Wicket decodifica (desempaqueta los valores codificados) la URL de la petición sin importar la forma que tenga, Wicket lo interpreta de una única manera. El resultado de la decodificación es almacenado en un objeto de tipo RequestParameter.
Si observas los valores decodificados del objeto RequestParameter de la figura, puedes suponer qué hace la petición. La ruta de componente 2:actionLink hace referencia al componente con la ruta actionLink, que se encuentra en la página que Wicket conoce mediante el identificador 2. Wicket asigna números de versión cuando se producen cambios estructurales en las instancias de las páginas (por ejemplo, cuando se reemplazan, ocultan o se muestran componentes). En este caso, la versión de la página derivada de la decodificación de la URL es 0, lo que significa que nos encontramos ante la primera (sin modificar) instancia de la página.
En el siguiente paso, Wicket determina el RequestTarget. Wicket puede manejar diferentes tipos de peticiones -por ejemplo, páginas referenciables (el término en inglés es bookmarkable, es decir, páginas a las que podemos acceder poniendo la URL en el navegador), recursos compartidos, y peticiones AJAX. En la figura, la RequestTarget es una instancia de la clase ListenerInterfaceRequestTarget que encapsula la llamada a un enlace (interfaz ILinkListener) de una página previamente renderizada. En este caso, se obtiene la página previamente renderizada usando el identificador 2 y la versión 0, como puedes ver.
El tercer paso, procesamiento de los eventos, es opcional. Se usa para cosas como llamadas a enlaces o a comportamientos Ajax (los componentes en Wicket se pueden extender agregándoles comportamientos), pero no para páginas referenciables o para recursos compartidos. Durante el procesamiento de los eventos, la petición objetivo puede cambiar. Por ejemplo, esto puede ocurrir cuendo se llama a setResponsePage en el método onSubmit de un formulario, en cuyo caso una instancia de PageRequestTarget se usa para el resto del procesamiento de la petición. Llamando a setResponsePage es como más fácilmente se puede navegar de una página a otra cuando se manejan eventos como onClick u onSubmit.
El paso final es responder al cliente. Como ya se ha mencionado, el procesamiento final de una petición se delega al RequestTarget, que es el encargado de crear la respuesta. Un PageRequestTarget se ocupa de renderizar una página y enviarlar al cliente, un ShareResourceRequestTarget se encarga de localizar un recurso (un imagen por ejemplo) y enviarla al cliente, y un AjaxRequestTarget se encarga de renderizar componentes individuales y generar una respuesta XML que la librería Ajax del cliente pueda interpretar
