Reputation: 83203
The situation:
Current approach:
The problem:
Other modules should be able to perform some routines based on the database entities that are modified in the file parse routine described above; how can I register a front controller plugin that executes after this is done?
Zend_Controller_Plugin
objects are executed in LIFO order. Should I take another approach?
Note: I do realize that registerPlugin()
takes a second $stackIndex
argument, but since there is no way of knowing the current position of the stack, this is really is not a very clean way to solve the problem.
Upvotes: 1
Views: 453
Reputation: 40685
There is a way to know what stack indices have been used already. I recently wrote the following method for just such a case:
/**
*
* Returns the lowest free Zend_Controller_Plugin stack index above $minimalIndex
* @param int $minimalIndex
*
* @return int $lowestFreeIndex | $minimalIndex
*/
protected function getLowestFreeStackIndex($minimalIndex = 101)
{
$plugins = Zend_Controller_Front::getInstance()->getPlugins();
$usedIndices = array();
foreach ($plugins as $stackIndex => $plugin)
{
$usedIndices[$stackIndex] = $plugin;
}
krsort($usedIndices);
$highestUsedIndex = key($usedIndices);
if ($highestUsedIndex < $minimalIndex)
{
return $minimalIndex;
}
$lowestFreeIndex = $highestUsedIndex + 1;
return $lowestFreeIndex;
}
Basically, what you're asking for is the part Zend_Controller_Front::getInstance()->getPlugins();
With that you can do whatever you want, the array contains all the used stack indices as keys.
The function starts returning stack indices from 101 because the Zend Framework error controller plugin uses 100 and I need to register mine with higher indices. That's of course a bit of a magic number, but even the Zend Framework tutorials/manuals don't have a better solution for the 101 stack index problem. A class constant would make it a bit cleaner/more readable.
Upvotes: 2