Hey, thanks Pete! Fair enough. I catch the distinction. But my end question is still in essence the same. If I have a need for some dynamic "routing", I can do it essentially many different ways, and I'm looking to find what I am missing in terms of the pros/cons of those ways.
For example, if I wanted to check to see if a user is authenticated, and based on various criteria determine if access to controller 'foo' should be re-routed to a different page:
1) I could create a RouteFactory class that feeds routes based on the request parameters. I believe I could even use Zend_Auth and Zend_Acl within that factory class when creating routes, and coupled with instantiating the session also have access to persistent session data when building routes. In essence it seems to me I can make routing decisions based on everything I would ever want to know about the request, authentication status, etc. So no access can result in a route created that routes to a login page. If the conditions for access to 'bar' are not met, I can route to an index landing page. If they are, I can simply not create a route at all and let it go through.
or
2) I could in essence do all the same things in a preDispatch method of a controller plugin. But instead of creating routes, I'm simply altering the request object like this: $request->setControllerName('bar') based on essentially the same criteria. I could use the session data, Zend_Auth, and Zend_Acl to build the rules and then the result of those rules is altering the request object, or not.
Or simply put, the basic algorithm of my ACL generator is identical, how I gather the input is a little different but after it all goes through the salad spinner, the last bit of code is like this:
if (!$acl->isAllowed($role, 'foo', $privilege)) {
//create some routes for the router to
}
if (!$acl->isAllowed($role, 'foo', $privilege)) {
// $request->setControllerName('bar')
// ->setActionName('index');
// etc
}
I'm not seeing a major distinction or advantage of doing one or the other, but then again, I don't have tons of experience with ZF to catch all the nuances, which is why I'm reaching out. Perhaps the router doesn't have access to POST parameters?? That would be important to my app. Does the router have access to the request object? If not another limitation might be that you can't add or change other parameters in the request object directly (though I could just store the same in the session namespace as an alternative as a workaround). Thanks a ton for your help!
--Seth
From: Peter Warnock [mailto:petewarnock@gmail.com]
Sent: Tuesday, July 28, 2009 12:58 AM
To: Atkins, Seth (RICH1:5278)
Cc: fw-mvc@lists.zend.com
Subject: Re: [fw-mvc] router vs pre-dispatch
I'm curious about when I should use routing or pre-dispatch for altering a request. Both can in effect accomplish re-routing, and I'm not real familiar with the pros and cons of either. In pre-dispatch, I can create a custom plugin that looks at the request and then changes the request object module/controller/action as a result.
The router maps the request to the module, controller, action and sets defaults before the controller is instantiated and pre-dispatch called. It's job isn't to modify the request, rather it's job is to gather the parameters from the request and route.
The reason you see ACLs in the pre-dispatch is that the request matches a controller, but there is something missing, like an authenticated session. If the request is repeated with an authenticated session, it's not redirected to login.
- pw
没有评论:
发表评论