Web Oriented Object Framework

User Guide (Version 0.5b4)

Woof!
User Guide (Version 0.5b4)

URL Mapping

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:

scheme and authority 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.
url_root /myproduct

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 myproduct. In this case, the value of the url_root configuration variable would be set to /myproduct and in addition the hosting web server would be configured to invoke Woof! for all requests under it as described in the Installation chapter.

In the case where Woof! drives the entire web site (url_root will be /), this component need not be present.

module support Controllers implementing related functionality can be grouped into modules. This is an optional component and need not be always present.
controller ticket The next component is the controller which implements a support ticket tracking system.
action display This specifies the action method to be invoked in the controller, which in this case specifies a page showing a support ticket.
parameters id=123 This optional component specifies parameters to be passed to the action method. The parameters can be retrieved through the params object.
fragment 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

or, even

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.