Director is the first step in the "execution pipeline". It parses the URL, matching it to one of a number of patterns, and determines the controller, action and any argument to be used. It then runs the controller, which will finally run the viewer and/or perform processing steps.
- File uploads are first analysed to remove potentially harmful uploads (this will likely change!)
- The SS_HTTPRequest object is created
- The session object is created
- The Injector is first referenced, and asks the registered RequestProcessor to pre-process the request object. This allows for analysis of the current request, and allow filtering of parameters etc before any of the core of the application executes.
- The request is handled and response checked
- The RequestProcessor is called to post-process the request to allow further filtering before content is sent to the end user
- The response is output
The framework provides the ability to hook into the request both before and after it is handled to allow developers to bind in their own custom pre- or post- request logic; see the RequestFilter to see how this can be used to authenticate the request before the request is handled.
You can influence the way URLs are resolved in the following ways
- Adding rules to Director in
- Adding rules to Director in `<yourproject>/_config.php (deprecated)
- Adding rules in your extended Controller class via the $url_handlers static variable
See controller for examples and explanations on how the rules get processed for those methods.
SilverStripe comes with certain rules which map a URI to a Controller
class (e.g. dev/ -> DevelopmentAdmin). These routes are either stored in
a routes.yml configuration file located a
_config directory or inside a
_config.php file (deprecated).
To add your own custom routes for your application create a routes.yml file
<yourproject>/_config/routes.yml with the following format:
--- Name: customroutes After: framework/routes#coreroutes --- Director:
rules: 'subscriptions/$Action' : 'SubscriptionController'
The Controller documentation has a wide range of examples and explanations on how the rules get processed for those methods.
- Checking for an Ajax-Request: Use Director::is_ajax() instead of checking for $_REQUEST['ajax'].
- See ModelAsController class for details on controller/model-coupling
- See execution-pipeline for custom routing