My application needs to manage several contexts, which each one of them should manage several resources. For example:
/app/john/cars/add
/app/john/cars/edit
/app/john/cars/delete
/app/john/wheels/add
/app/john/wheels/edit
/app/john/wheels/delete
/app/mike/cars/add
/app/mike/cars/edit
/app/mike/cars/delete
/app/mike/wheels/add
/app/mike/wheels/edit
/app/mike/wheels/delete
I'm wondering if I should declare this global "context" variable on the !Route of EVERY method (i.e. !Route /$context/cars/add) or if there's a better way to achieve this.
Ideas?
Not sure if this question is appropriated to this forum though.
falmp,
Great question. Common elements of a route shared across a controller can be extracted to the !RoutesPrefix annotation on a controller.
So your app's $routingPrefix could be: app/
On your controller: !RoutesPrefix $context/
Then on your individual methods:
/** !Route GET, wheels/ */
function showWheels($context) { ... }
Notice that on the !Route annotation there is no leading slash. Similar to unix paths, this makes it a relative route so that it then looks to the controller's and app's prefixes to build the full route: /app/$context/wheels
For a full explanation of relative vs. static routing check-out: http://www.recessframework.org/page/routing-in-recess-screencast
I also want to urge you to consider not using the /add, /edit, /delete URLs with GET. It's not RESTful. The HTTP protocol has different methods to support adding, editing, and deleting resources (POST, PUT, DELETE). If you generate scaffolding for a Model in Recess Tools you will see how these methods can be put to use.
Lastly, the !RoutesPrefix is being replaced in 0.20 with a simpler !Prefix annotation that allows you to specify both the view template prefix and the routing prefix. Just a heads up!
Kris,
Thanks for the explanation. I was wondering if I should do it creating an Annotation, like !HasContext, that would automatically attach/set the property on the controllers. But then I I'd have to mess with the routes, I guess it's better to keep it simple and explicitly declare as parameter the $context on every method.
By the way, yes, I'll use the different methods, it was just an example. Actually I convinced myself just the other day, while I noticed that otherwise I'd have to "switch" on the "action" to decide what to do with the request. Better simplify it using the different methods and also make it RESTful along the way. :)