localized url's

[Andries Seutens]

Hi all,

Sorry to bring this topic up again...

I have a little issue with the url helper and route matching. I think
this is a critical missing feature / bug.
I'm going to try to explain my issue by example:

My bootstrap file:

----------

set_include_path('./ZendFramework-1.5.1/library');

require_once 'Zend/Loader.php';
Zend_Loader::registerAutoLoad();

$frontController = Zend_Controller_Front::getInstance();
$frontController->addControllerDirectory('./application/controllers')
    ->throwExceptions(true)
    ->returnResponse(true);

$router = $frontController->getRouter();
$router->addRoute('foo', new Zend_Controller_Router_Route(
    ':lang/foo',
    array(
        'lang'       => 'nl',
        'controller' => 'index',
        'action'     => 'index'
    )
));

$router->addRoute('bar', new Zend_Controller_Router_Route(
    ':lang/bar',
    array(
        'lang'       => 'nl',
        'controller' => 'index',
        'action'     => 'index'
    )
));

$response = $frontController->dispatch();
$response->sendHeaders()
    ->outputBody();

----------

My template file:

----------

<?php echo $this->url(array(), 'foo') ?>
<br />
<?php echo $this->url(array(), 'bar') ?>

----------

when i call: http://mydomain/nl/bar
the output is:

/nl/foo
/nl/bar

which is good!

if i call: http://mydomain/en/foo
the output is

/en/foo
/en/bar

which is good too!

the problem occurs when the last route in the row is matched (in this
case: 'bar')

http://test/en/bar

output:

/nl/foo
/en/bar

works for all routes after the matched one, but not the ones before.....

In order for this to work I would need to pass in the 'lang' parameter:

<?php echo $this->url(array('lang' =>
Zend_Controller_Front::getInstance()->getRequest()->getParam('lang')),
'foo') ?>

So, in other words: I am unable to take a url param into each route and
use it with the url helper?

Best,



Andriesss




Gecontroleerd op virussen door de JOJO Secure Gateway.

[Andries Seutens]

Hi all,

Attached is a patch to the problem indicated below.

@Martel: could you evaluate this patch and see if it's a reasonable
solution?

Thanks!

Andriesss

Andries Seutens schreef:

>
> Hi all,
>
> Sorry to bring this topic up again...
>
> I have a little issue with the url helper and route matching. I think
> this is a critical missing feature / bug.
> I'm going to try to explain my issue by example:
>
> My bootstrap file:
>
> ----------
>
> set_include_path('./ZendFramework-1.5.1/library');
>
> require_once 'Zend/Loader.php';
> Zend_Loader::registerAutoLoad();
>
> $frontController = Zend_Controller_Front::getInstance();
> $frontController->addControllerDirectory('./application/controllers')
>    ->throwExceptions(true)
>    ->returnResponse(true);
>
> $router = $frontController->getRouter();
> $router->addRoute('foo', new Zend_Controller_Router_Route(
>    ':lang/foo',
>    array(
>        'lang'       => 'nl',
>        'controller' => 'index',
>        'action'     => 'index'
>    )
> ));
>
> $router->addRoute('bar', new Zend_Controller_Router_Route(
>    ':lang/bar',
>    array(
>        'lang'       => 'nl',
>        'controller' => 'index',
>        'action'     => 'index'
>    )
> ));
>
> $response = $frontController->dispatch();
> $response->sendHeaders()
>    ->outputBody();
>
> ----------
>
> My template file:
>
> ----------
>
> <?php echo $this->url(array(), 'foo') ?>
> <br />
> <?php echo $this->url(array(), 'bar') ?>
>
> ----------
>
> when i call: http://mydomain/nl/bar
> the output is:
>
> /nl/foo
> /nl/bar
>
> which is good!
>
> if i call: http://mydomain/en/foo
> the output is
>
> /en/foo
> /en/bar
>
> which is good too!
>
> the problem occurs when the last route in the row is matched (in this
> case: 'bar')
>
> http://test/en/bar
>
> output:
>
> /nl/foo
> /en/bar
>
> works for all routes after the matched one, but not the ones before.....
>
> In order for this to work I would need to pass in the 'lang' parameter:
>
> <?php echo $this->url(array('lang' =>
> Zend_Controller_Front::getInstance()->getRequest()->getParam('lang')),
> 'foo') ?>
>
> So, in other words: I am unable to take a url param into each route
> and use it with the url helper?
>
> Best,
>
>
>
> Andriesss
>
>
>
> ------------------------------------------------------------------------
>
> Gecontroleerd op virussen door de JOJO Secure Gateway.
>  
> ------------------------------------------------------------------------
>
> No virus found in this incoming message.
> Checked by AVG.
> Version: 7.5.524 / Virus Database: 269.23.8/1415 - Release Date: 5/05/2008 6:01
>  

Index: Url.php
===================================================================
--- Url.php (revision 9357)
+++ Url.php (working copy)
@@ -59,13 +59,16 @@
                 $name = 'default';
             }
         }
-        
+
         if ($encode) {
             foreach ($urlOptions as $key => $option) {
                 $urlOptions[$key] = ($option !== null) ? urlencode($option) : $option;
             }
         }
 
+        $params = $front->getRequest()->getUserParams();
+        $urlOptions = array_merge($urlOptions, $params);
+
         $route = $router->getRoute($name);
 
         $url = rtrim($front->getBaseUrl(), '/') . '/';

Gecontroleerd op virussen door de JOJO Secure Gateway.

[Michał Minicki]

Andries Seutens wrote:

> Attached is a patch to the problem indicated below.
> @Martel: could you evaluate this patch and see if it's a reasonable
> solution?

Well, it's a fragile topic, actually. Your patch would probably break some existent
code, so it can't be merged in minor release. In fact I would rather go for 2.0 branch.

The problem is described in greater detail in a thread Simon started back in March. Take
a look -- basically it's the same problem if I get your meaning correctly:

http://www.nabble.com/forum/ViewPost.jtp?post=16512438&framed=y

For now I can assure you I know about the issue and I guess we (as in ZF developers and
contributors) should come up with a solution but we have to keep the routes separated at
the same time. And to be frank, I haven't had the time to think it through yet. What
comes to mind is:

- a parameter to assemble method
- a second helper (in order to avoid interface modification)
- maybe some router level solution

For now just use your own modified url helper.

> Andriesss

--
Michał Minicki aka Martel Valgoerad | martel@... | http://aie.pl/martel.asc
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
"Idleness is not doing nothing. Idleness is being free to do anything." --
Floyd Dell

[Andries Seutens]

Hi Martel,

Thanks for your prompt response.

Why then does the parameter work for routes following the matched route,
and not for those preceding it? Could you provide me a scenario where
the current behaviour would be an actual use case?

I'd say we introduce a new static method, in which we are able to
enable/disable this functionallity. By default it'd be disabled, to
remain BC.

Let's strive for "extreme simplicity", and make our lives easier.

Best,

Andriesss

Michał Minicki schreef:

> Andries Seutens wrote:
>
>> Attached is a patch to the problem indicated below.
>> @Martel: could you evaluate this patch and see if it's a reasonable
>> solution?
>
> Well, it's a fragile topic, actually. Your patch would probably break
> some existent code, so it can't be merged in minor release. In fact I
> would rather go for 2.0 branch.
>
> The problem is described in greater detail in a thread Simon started
> back in March. Take a look -- basically it's the same problem if I get
> your meaning correctly:
>
> http://www.nabble.com/forum/ViewPost.jtp?post=16512438&framed=y
>
> For now I can assure you I know about the issue and I guess we (as in ZF
> developers and contributors) should come up with a solution but we have
> to keep the routes separated at the same time. And to be frank, I
> haven't had the time to think it through yet. What comes to mind is:
>
> - a parameter to assemble method
> - a second helper (in order to avoid interface modification)
> - maybe some router level solution
>
> For now just use your own modified url helper.
>
>> Andriesss
>

[Michał Minicki-2]

Andries Seutens wrote:

> Why then does the parameter work for routes following the matched route,
> and not for those preceding it? Could you provide me a scenario where
> the current behaviour would be an actual use case?

This is a great point, Andries. It probably works for every route that has been tested
for a match. And the question is whether it should work only for the current route or
not. This is something that needs to be taken into consideration.

> I'd say we introduce a new static method, in which we are able to
> enable/disable this functionallity. By default it'd be disabled, to
> remain BC.

This is another nice idea.

Here are two more:

- Instead of returning the first match, match every single route and return the "most"
fitting one, ie. longest, that matched the biggest number of route parts (Spring
framework does that with it's simple url mapper, btw). This will initialize all the
routes. BC break highly probable.

- Initialize every route with a request object in Router's addRoute(). Take URL
parameters directly out of request (on demand) instead of using copies stored in the
url. This probably wouldn't introduce a BC break and will resolve another issue - whole
Request access in the routes (hint: subdomain matching).

Then again, url helper business logic should probably be moved to Router in order to
keep business logic in the controller/business parts. Action helper and View helper
should then call this single source in order to create the resulting URLs.

> Let's strive for "extreme simplicity", and make our lives easier.

I agree. But let's do this properly instead of hacking a quick and dirty solution :)

> Andriesss

--
Michał Minicki aka Martel Valgoerad | martel@... | http://aie.pl/martel.asc
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
"Idleness is not doing nothing. Idleness is being free to do anything." --
Floyd Dell

[Andries Seutens]

Hi Martel,

See comments inline.

Michał Minicki schreef:

> Andries Seutens wrote:
>
>> Why then does the parameter work for routes following the matched
>> route, and not for those preceding it? Could you provide me a scenario
>> where the current behaviour would be an actual use case?
>
> This is a great point, Andries. It probably works for every route that
> has been tested for a match. And the question is whether it should work
> only for the current route or not. This is something that needs to be
> taken into consideration.
>
>> I'd say we introduce a new static method, in which we are able to
>> enable/disable this functionallity. By default it'd be disabled, to
>> remain BC.
>
> This is another nice idea.
>
> Here are two more:
>
> - Instead of returning the first match, match every single route and
> return the "most" fitting one, ie. longest, that matched the biggest
> number of route parts (Spring framework does that with it's simple url
> mapper, btw). This will initialize all the routes. BC break highly
> probable.

How would this fix the issue?


>
> - Initialize every route with a request object in Router's addRoute().
> Take URL parameters directly out of request (on demand) instead of using
> copies stored in the url. This probably wouldn't introduce a BC break
> and will resolve another issue - whole Request access in the routes
> (hint: subdomain matching).


This is what i've done in my patch. I used the request object's
getUserParams() methods, because this is the only way to guarantee that
we're only assembling the user parameters into the url.

If you're afraid of a BC break, i'd suggest to simply introduce a flag
to turn this behaviour on/off. However, I really wonder if there's an
actual use case for such behaviour.

>
> Then again, url helper business logic should probably be moved to Router
> in order to keep business logic in the controller/business parts. Action
> helper and View helper should then call this single source in order to
> create the resulting URLs.
>
>> Let's strive for "extreme simplicity", and make our lives easier.
>
> I agree. But let's do this properly instead of hacking a quick and dirty
> solution :)
>
>> Andriesss
>

Best,

Andriesss

[Michał Minicki]

Andries Seutens wrote:

>> - Instead of returning the first match, match every single route and
>> return the "most" fitting one, ie. longest, that matched the biggest
>> number of route parts (Spring framework does that with it's simple url
>> mapper, btw). This will initialize all the routes. BC break highly
>> probable.
> How would this fix the issue?

All routes would be tested for a match resulting in initialization of local route
attributes. So basically all the routes would hold immutable copy of related URL
parameters, which on the other hand would result in what you wish to accomplish. This
solution wouldn't have a risk of working on user tainted request data. Unlike the second
solution.

>> - Initialize every route with a request object in Router's addRoute().
>> Take URL parameters directly out of request (on demand) instead of using
>> copies stored in the url. This probably wouldn't introduce a BC break
>> and will resolve another issue - whole Request access in the routes
>> (hint: subdomain matching).
> This is what i've done in my patch. I used the request object's
> getUserParams() methods, because this is the only way to guarantee that
> we're only assembling the user parameters into the url.

Right. But at the same time we're storing request parameters in the routes for naught,
we process them in the routes wasting cpu time and we're doing part of the assembly in
the route (assemble) and part outside (in url helper) which is just not pure in my eyes.

Don't get me wrong, it's a good solution, Andries - it will meet your needs and it
should be all that matters to you. So just keep a copy of the modified URL helper for
now and let's do it at the framework level in a more fitting manner.

> If you're afraid of a BC break, i'd suggest to simply introduce a flag
> to turn this behaviour on/off. However, I really wonder if there's an
> actual use case for such behaviour.

I'm not. Matthew is the evil BC guardian here. Albeit necessary ;)

You just can't break people's code.

Andries, create a Jira issue and assign it directly to me. I'll try to come up with
something this week (maybe on the weekend) and I'll address couple of issues at once.

I'll submit to incubator then.

--
Michał Minicki aka Martel Valgoerad | martel@... | http://aie.pl/martel.asc
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
"Idleness is not doing nothing. Idleness is being free to do anything." --
Floyd Dell

[Matthew Weier O'Phinney-3]

-- Michał Minicki <martel@...> wrote
(on Monday, 05 May 2008, 09:33 PM +0200):

> Andries Seutens wrote:
>
> > > - Instead of returning the first match, match every single route and  
> > > return the "most" fitting one, ie. longest, that matched the biggest  
> > > number of route parts (Spring framework does that with it's simple
> > > url mapper, btw). This will initialize all the routes. BC break
> > > highly probable.
> > How would this fix the issue?
>
> All routes would be tested for a match resulting in initialization of
> local route attributes. So basically all the routes would hold immutable
> copy of related URL parameters, which on the other hand would result in
> what you wish to accomplish. This solution wouldn't have a risk of
> working on user tainted request data. Unlike the second solution.
>
> > > - Initialize every route with a request object in Router's
> > > addRoute(). Take URL parameters directly out of request (on demand)
> > > instead of using copies stored in the url. This probably wouldn't
> > > introduce a BC break and will resolve another issue - whole Request
> > > access in the routes (hint: subdomain matching).
> > This is what i've done in my patch. I used the request object's  
> > getUserParams() methods, because this is the only way to guarantee that
> > we're only assembling the user parameters into the url.
>
> Right. But at the same time we're storing request parameters in the
> routes for naught, we process them in the routes wasting cpu time and
> we're doing part of the assembly in the route (assemble) and part outside
> (in url helper) which is just not pure in my eyes.
>
> Don't get me wrong, it's a good solution, Andries - it will meet your
> needs and it should be all that matters to you. So just keep a copy of
> the modified URL helper for now and let's do it at the framework level in
> a more fitting manner.
>
> > If you're afraid of a BC break, i'd suggest to simply introduce a flag  
> > to turn this behaviour on/off. However, I really wonder if there's an  
> > actual use case for such behaviour.
>
> I'm not. Matthew is the evil BC guardian here. Albeit necessary ;)
>
> You just can't break people's code.

If you default the flag to have the current behavior, but allow setting
the flag to have the new, desired behavior, it's not a BC break, and I'm
fine with that.

> Andries, create a Jira issue and assign it directly to me. I'll try to
> come up with something this week (maybe on the weekend) and I'll address
> couple of issues at once.
>
> I'll submit to incubator then.

If you do as above, you can do it directly in trunk.

--
Matthew Weier O'Phinney
Software Architect       | matthew@...
Zend - The PHP Company   | http://www.zend.com/

[Michał Minicki]

Michał Minicki <martel@...> napisał(a):

>> This is what i've done in my patch. I used the request object's
>> getUserParams() methods, because this is the only way to guarantee
>> that we're only assembling the user parameters into the url.
>
> Right. But at the same time we're storing request parameters in the
> routes for naught, we process them in the routes wasting cpu time and
> we're doing part of the assembly in the route (assemble) and part
> outside (in url helper) which is just not pure in my eyes.

Something occurred to me after a good nights sleep - when you do this in
the view helper, Andries, and you have duplicated existent parameters in
the request, you're basically overwriting all parameters or not overwriting
them at all which should not be the case. You want to overwrite route
defaults but not a user supplied parameters.



--
Martel Valgoerad aka Michal Minicki | martel@... | http://aie.pl/martel.asc
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
"Idleness is not doing nothing. Idleness is being free to do anything."
 -- Floyd Dell

[Michał Minicki]

>> Andries, create a Jira issue and assign it directly to me. I'll try to
>> come up with something this week (maybe on the weekend) and I'll
>> address couple of issues at once.
>> I'll submit to incubator then.
> If you do as above, you can do it directly in trunk.

I guess I'll try with injecting Request object on addRoute() step. It
should be backwards compatible this way. Well, at least when it comes to
interfaces. But it could lead to different behavior at the same time as all
routes would use current request parameters (which both Andries and Simon
want to have).

If I will have any gut feeling that the resulting code would change route's
behavior I'll commit to incubator first and ask for some testing.



--
Martel Valgoerad aka Michal Minicki | martel@... | http://aie.pl/martel.asc
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
"Idleness is not doing nothing. Idleness is being free to do anything."
 -- Floyd Dell

[Andries Seutens]

Martel,

I see where your problem is .... I have taken this into account and
created a new patch (see attached).

This patch allows you to staticly bind certain params to each route.

How to use:
Zend_View_Helper_Url::staticBind('lang'); // can also provide an array
to bind mulitple keys

This will bind the "lang" paramter to each route. If you don't bind
params, the current behaviour will remain.

Could you and Matthew please consider this patch?

Best,


Andriesss

Michał Minicki schreef:

>>> Andries, create a Jira issue and assign it directly to me. I'll try to
>>> come up with something this week (maybe on the weekend) and I'll
>>> address couple of issues at once.
>>> I'll submit to incubator then.
>>>      
>> If you do as above, you can do it directly in trunk.
>>    
>
> I guess I'll try with injecting Request object on addRoute() step. It
> should be backwards compatible this way. Well, at least when it comes to
> interfaces. But it could lead to different behavior at the same time as all
> routes would use current request parameters (which both Andries and Simon
> want to have).
>
> If I will have any gut feeling that the resulting code would change route's
> behavior I'll commit to incubator first and ask for some testing.
>
>
>
>  

Index: Url.php
===================================================================
--- Url.php (revision 9357)
+++ Url.php (working copy)
@@ -36,6 +36,27 @@
     public $view;
 
     /**
+     * @var array
+     */
+    protected static $_staticBinds = array();
+
+    /**
+     * Allows you to staticly bind parameters to routes
+     *
+     * @param mixex $urlOptions - an array of static parameters to bind to each route
+     */
+    public static function staticBind($urlOptions)
+    {
+        if (is_array($urlOptions)) {
+            foreach ($urlOptions as $option) {
+                self::$_staticBinds[(string) $option] = true;
+            }
+        } else {
+            self::$_staticBinds[(string) $urlOptions] = true;
+        }
+    }
+
+    /**
      * Generates an url given the name of a route.
      *
      * @access public
@@ -47,9 +68,7 @@
      */
     public function url(array $urlOptions = array(), $name = null, $reset = false, $encode = true)
     {
-
-        $front = Zend_Controller_Front::getInstance();
-
+        $front  = Zend_Controller_Front::getInstance();
         $router = $front->getRouter();
 
         if (empty($name)) {
@@ -59,20 +78,28 @@
                 $name = 'default';
             }
         }
-        
+
         if ($encode) {
             foreach ($urlOptions as $key => $option) {
                 $urlOptions[$key] = ($option !== null) ? urlencode($option) : $option;
             }
         }
 
+        $staticBinds = array();
+        foreach ($front->getRequest()->getParams() as $key => $value) {
+            if (isset(self::$_staticBinds[$key])) {
+                $staticBinds[$key] = ($value !== null && $encode) ? urlencode($value) : $value;
+            }
+        }
+
+        $urlOptions = array_merge($staticBinds, $urlOptions);
+
         $route = $router->getRoute($name);
 
         $url = rtrim($front->getBaseUrl(), '/') . '/';
         $url .= $route->assemble($urlOptions, $reset);
 
         return $url;
-
     }
 
     /**

Gecontroleerd op virussen door de JOJO Secure Gateway.

[Michał Minicki]

Michał Minicki wrote:

> I guess I'll try with injecting Request object on addRoute() step. It
> should be backwards compatible this way. Well, at least when it comes to
> interfaces. But it could lead to different behavior at the same time as all
> routes would use current request parameters (which both Andries and Simon
> want to have).

Well, I have made a choice to introduce Andriess' improvement without any significant
changes to the business logic, so the whole thing is fully backwards compatible. However
this may change assembly behavior on some setups! But as route assemblies were
inconsistent earlier (as Andries pointed it out), I have made a choice to fix that anyway.

I have commited it to the 1.5 branch (to be included in next minor release) since those
inconsistencies should be rare. In fact they should appear only on the url creation when
you use a named route (which is not a current route), rely on it's defaults and it is a
route that wasn't matched on this request. Since one should be using reset flag on such
occasions anyway, I guess it shouldn't be a problem. And if one observes a different
behavior, one should add a reset flag on the url view helper call to get the desired effect:

So instead of: $this->url(array(...), 'named-route');
One should do: $this->url(array(...), 'named-route', true);

Now, from a technical standpoint:

I have made a choice to initialize all the routes and keep full backwards compatibility
at the cost of speed - this can introduce a slight performance hit, especially when one
have lots of sophisticated routes. So, from now on we have to pay attention to any
issues regarding speed. I haven't benchmarked the change but there is one thing to note:
tests still run the same number of seconds as before.

Now, I still do plan on injecting the Request object to every route. This will speed
things up and speed will be back to normal or even better than before. But this change
requires change in Router interface as well as in Router initialization in front
controller. This will result in framework components modifications only, so no user code
will have to be changed unless they subclassed the router or created a custom one
themselves. So it would be a major version fix, I guess. And the question is: incubator
or trunk?

--
Michał Minicki aka Martel Valgoerad | martel@... | http://aie.pl/martel.asc
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
"Idleness is not doing nothing. Idleness is being free to do anything." --
Floyd Dell

[Michał Minicki]

Michał Minicki wrote:

> Well, I have made a choice to introduce Andriess' improvement without any significant
> changes to the business logic, so the whole thing is fully backwards compatible. However
> this may change assembly behavior on some setups! But as route assemblies were
> inconsistent earlier (as Andries pointed it out), I have made a choice to fix that anyway.

Oh, and one more thing - this change does not mean that all routes will use request
variables. It merely fixes inconsistencies Andriess pointed out on his first mail in the
thread.

--
Michał Minicki aka Martel Valgoerad | martel@... | http://aie.pl/martel.asc
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
"Idleness is not doing nothing. Idleness is being free to do anything." --
Floyd Dell

[Andries Seutens]

Martel,

Did you commit the fix into trunk yet? Can't seem to find it.

do you have a revision number?

Thanks!

Andriesss

Michał Minicki schreef:

> Michał Minicki wrote:
>
>> Well, I have made a choice to introduce Andriess' improvement without
>> any significant changes to the business logic, so the whole thing is
>> fully backwards compatible. However this may change assembly behavior
>> on some setups! But as route assemblies were inconsistent earlier (as
>> Andries pointed it out), I have made a choice to fix that anyway.
>
> Oh, and one more thing - this change does not mean that all routes
> will use request variables. It merely fixes inconsistencies Andriess
> pointed out on his first mail in the thread.
>

Gecontroleerd op virussen door de JOJO Secure Gateway.

[Michał Minicki]

Andries Seutens wrote:
> Martel,
>
> Did you commit the fix into trunk yet? Can't seem to find it.
> do you have a revision number?

http://framework.zend.com/code/changelog/Zend_Framework?cs=9390

I have added three tests for this change. You may want to take a look there as well.

> Andriesss

--
Michał Minicki aka Martel Valgoerad | martel@... | http://aie.pl/martel.asc
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
"Idleness is not doing nothing. Idleness is being free to do anything." --
Floyd Dell

[Michał Minicki]

Michał Minicki wrote:

>> Did you commit the fix into trunk yet? Can't seem to find it.
>> do you have a revision number?
> http://framework.zend.com/code/changelog/Zend_Framework?cs=9390
> I have added three tests for this change. You may want to take a look there as well.

I reverted the change (even from the trunk) today. See Christer's issue:

http://framework.zend.com/issues/browse/ZF-3219

I have fixed the inconsistency in the exact opposite way, Andries. It will behave like
this (as it should from the beginning):

http://mydomain/       => /nl/foo, /nl/bar
http://mydomain/en/foo => /en/foo, /nl/bar
http://mydomain/en/bar => /nl/foo, /en/bar

I will implement a way to inject matched parameters to different routes, though. Just
not yet.

--
Michał Minicki aka Martel Valgoerad | martel@... | http://aie.pl/martel.asc
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
"Idleness is not doing nothing. Idleness is being free to do anything." --
Floyd Dell

[Andries Seutens]

look at the patch i sent, it does just that ...

Andriesss

Michał Minicki schreef:

> Michał Minicki wrote:
>
>>> Did you commit the fix into trunk yet? Can't seem to find it.
>>> do you have a revision number?
>>