ZF-6065: Zend_Controller_Router_Route_Regexp does not honor $reset parameter
I posted this message to the mailing list but got no feedback so I am going to proceed under the assumption that this is infact a real bone-fide bug! http://thread.gmane.org/gmane.comp.php.zend.framew…
In Zend_View_Helper_Url the reset parameter is documented as: "Whether or not to reset the route defaults with those provided".
I've always taken this to mean that if the route being assembled is the same as the one matched on the current request, do not use the values extracted from the current request when assembling if this argument is true.
Assuming I am correct, when I look at the assemble() method of Zend_Controller_Router_Route_Regex it's clearly evident that the $reset parameter is completely ignored and $this->_values is always used.
So under this logic, it is impossible to e.g. link to the same route as currently matched but with different values for some params, but leaving others to be filled in by their default values when said missing params were actually supplied in the currently matched route!
Phew, that last sentence was a hard one to follow, so I'll do an example.
Say I have a route:
new Zend_Route_Regex( 'foo(?:/([\w-]+)(?:/([0-9]+))?)?', array('module' => 'blah', 'controller' => 'blah', 'action' => 'blah', 'arg1' => bar, 'arg2' => 1), array(1 => 'arg1', 2 => 'arg2') );
If the following URL is matched /foo/bar/42
And I use a view helper to create a new link on that page via: $this->url(array('arg1' => 'oink'), null, true);
Then I'd expect a route of: /foo/oink to be produced (because null will match the current route, and true says the current values should be ignored.
However this actually produces a route: /foo/oink/42
As the value matched in the current route is not reset as you would expect.
This is the same regardless of the $reset parameter so: $this->url(array('arg1' => 'oink'), null, false); will also produce the same result: /foo/oink/42