Matthew, Thanks for your extremely detailed reply. I wonder how you have time to get any coding done from answering all us boneheads out here... ;)
In your response (which was highly informative) you wrote: Matthew Weier O'Phinney-3 wrote: > > 5. dispatchLoopStartup() > * call plugins registered with this hook > 6. preDispatch() > * call plugins registered with this hook > 7. Dispatch action > 8. action helper preDispatch() > 9. action controller preDispatch() > 10. action method > * UNLESS a _forward() or redirect has occurred > 11. action controller postDispatch() > 12. action helper postDispatch() > 13. postDispatch() > * call plugins registered with this hook > /* repeat 6 - 13 as necessary */ > 14. dispatchLoopShutdown() > * call plugins registered with this hook > 15. send response > First, I didn't realize that dispatchLoopStartup() and dispatchLoopShutdown() were available hooks for plugins. Second, it would be noteworthy to indicate that plugins and helpers registered are triggered _prior_ to the preDispatch() method and _after_ the postDispatch() method in the Controller. I'm still a little unclear on how the _forward() method is triggered... It seems to be outside of the regular flow but dependent on when the request occurs. Later in your response: Matthew Weier O'Phinney-3 wrote: > > _forward() does two things. If called in preDispatch() (any of them), it > will halt execution of the current action, and cause a new iteration of > the loop. When called during an action or during postDispatch() (any of > them), it will trigger an additional iteration of the dispatch loop. > I presume this has to do with the method by which the _forward() method performs its magic, then? Altering the action in the Request object in preDispatch(), which occurs before the Dispatcher calls the action method on the Controller, effectively alters the action to be performed, and unflagging isDispatched triggers the Dispatcher to run through the whole dispatch loop again. If the forward call is made in preDispatch(), however, it seems like pushing through another dispatch loop is undesirable, since all we really wanted was to deflect one action to another, whether in another Controller, Module, or the same. I can understand running preDispatch() again for the new action, but completing the current dispatch loop and running another one seems unnecessary and borderline undesirable. When called in the action or postDispatch() methods, the Dispatcher ignores the isDispatched flag until it hits its own postDispatch()...? Is that correct? My original understanding of _forward() (which I now understand to be incorrect), based on the documentation, was that it immediately interrupted the dispatch loop and reinitiated it with the new action (and optional Controller and Module specification). Again, maybe my current (corrected) understanding of the flow needs adjustment. Please correct further, if necessary. Matthew Weier O'Phinney-3 wrote: > > If you feel this could be made clearer in the manual, please open an > issue; > ideally, please submit a patch to the manual docbook. > I do love clarifying things, so I'll definitely do so...! I love this project dearly (been on since 0.6), and I'm eager to contribute something meaningful to it! Again, thanks a ton for your insight, Matthew! David @ OrlandoPHP.org -- View this message in context: http://www.nabble.com/Reagrding-the-current-Dispatch-process...-tp18635886p18654666.html Sent from the Zend Framework mailing list archive at Nabble.com.
