Note: The current URL dispatcher in Woof! is still somewhat experimental and likely undergo significant change before the 1.0 release.
A URL received in a request has to be mapped to a specific controller and action. For example, consider the following URL broken up as per the RFC3986 URI specification:
http://www.mycompany.com/myproduct/support/ticket/display?id=123#section \___/ \_______________/\_______________________________/ \____/\______/ | | | | | scheme authority path query fragment
From the Woof! perspective, the same URL is broken up as follows:
http://www.mycompany.com/myproduct/support/ticket/display?id=123#section \___/ \_______________/\________/ \_____/ \____/ \_____/ \____/\______/ | | | | | | | | scheme authority url_root | controller | parameters | module action fragment
The components in this particular URL may be broken down as follows:
||http://www.mycompany.com||The protocol and host specification have very little to do with Woof!. Basically, these components are used by the client and network infrastructure to deliver the request to the web server under which our Woof! site is installed.|
In our example, this is the root URL for our Woof! application. The
website may host many applications implemented using various
technologies. Woof! is used to implement the web site section for
In the case where Woof! drives the entire web site
||support||Controllers implementing related functionality can be grouped into modules. This is an optional component and need not be always present.|
||ticket||The next component is the controller which implements a support ticket tracking system.|
||display||This specifies the action method to be invoked in the controller, which in this case specifies a page showing a support ticket.|
||id=123||This optional component specifies parameters to be passed to the action method. The parameters can be retrieved through the params object.|
||section||This is actually never seen by Woof! in an incoming request. It is used strictly by the client to locate a particular section or fragment within received content. Woof! may however generate links that include this component in order to point clients to an exact location within a document.|
In the above example, the mapping from the URL to controller and action is fairly straighforward and done using Woof!'s default dispatch mapping.
However, in many instances it may be desirable to have a more flexible URL structure. For example, we may want ticket id to be passed as part of the URL which would then look like:
http://www.mycompany.com/myproduct/support/ticket/display/123 \___/ \_______________/\________/ \_____/ \____/ \_____/ \_/ | | | | | | | scheme authority url_root | controller | parameters module action
http://www.mycompany.com/myproduct/support/ticket/123 \___/ \_______________/\________/ \_____/ \____/ \_/ | | | | | | scheme authority url_root module | parameters controller
In the first case, the last component of the URL is the ticket number and not the name of the action method. In the second case, the action method is not even part of the URL. To accomplish this kind of custom dispatching of URL's, dispatch routes can be defined.
Both these mechanisms to map a URL to a controller and action are described in the next sections. The correspondence between the URL's and the corresponding actual controller class names and locations are described in the Implementing controllers chapter.