npacker
commented
9 years ago Slightly modified functionality - using the command pattern, paths map to actions. There really isn't a way around this for create/edit/delete operations as these need to be unique and unambiguous. However, view operations can conceivably be aliased based on the title. Once a discrete view layer is implemented, this functionality should be more feasible to work into the application structure.
Instead of instantiating the appropriate controller based on a URL parameter, an entire path is mapped to a controller and action. A path controller will be responsible for translating a URL to a controller and action.
Under the current implementation, the literal controller name is stored in the path. With the new method, the database will be queried against the path. The path table will have a path field and a controller field. The database query will return the controller name and action. This information will be passed from the path controller to the dispatcher, which will instantiate the given controller and pass control to it to execute the given action.
The path controller will basically be a front-end controller. Path->controller and path->action relationships will be stored in the database. The path model will be responsible for retrieving these, using the path as the look-up and returning the controller name and action. The path controller will then dispatch to either the appropriate content controller OR an HttpError controller if something goes wrong. This will allow error-checking logic to be mostly moved out of the Dispatcher and into a controller, which will decide how to handle it. This will free the Dispatcher to deal with a single task, rather than accounting for exceptional conditions.