Implemented bracketed optional parameters

[adrianmiu]

This allows one to create routes like

• [/{language}]/pages[.{type}] which will match /pages and /en/pages and /en/pages.json
• posts/archive[/{year}][/{month}][/{day}]

The generate() method makes sure that parameters that have the default value are not included. So, if the language default value is en the URL that will be generated will NOT start with /en

[adrianmiu]

BTW, the code coverage remains 100%

[harikt]

@adrianmiu Thank you.

@pmjones will check and respond.

[harikt]

short array, will not get passed in 5.3 .

[harikt]

So I have talked with @pmjones regarding this.

Please have a look into the discussion logs at http://colabti.org/irclogger/irclogger_log/auraphp?date=2014-01-30#l53 .

Thanks

[adrianmiu]

From the discussion it seems the problem is the array short notation from the $this->assertEquals(... which can easily be changed.
Otherwise I don't see the problem with having a second notation. ZF2 also uses the brackets to denote optional parameters (though they use :parameter_name to denote required parameters). I think that having {/language} is wrong for 3 reasons:

1. it introduces additional processing for handlebars segments (both in processing a route and generating a URL)
2. it has reduced readability. [/{language}] vs {/language}
3. it is more flexibile. You can have [_x_{language}] but you can't have {_x_language} (is this a required param or an optional one?)

[pmjones]

So, the issue of notation stems from the (admittedly non-accepted) RFC on URI templates. This comes from the fact that we already have an "optional" notation in the form of {/month,day,year} (note the slash inside the braces).

If we expand on that idea, the "required" notation for a required param would be {foo}, "optional" for a slash-prefixed param would be {/foo}, and "optional" for a dot-prefixed param would be {.foo}.

Whether that's the right thing to do or not is still a matter for discussion, but I do think it bears discussing.

Update: your point regarding "You can have[_x_{language}] but you can't have {_x_language}" is well-taken.

[pmjones]

Tell you what @adrianmiu -- fix the short-array stuff so it passes on 5.3, and I can merge it manually to play around with it. Then we can follow up after that. (FWIW I do see the value of the patch.)

[adrianmiu]

I've made the required changes for 5.3.
I've just finished looking (superficially mind you) at the URI templates RFC and the first thing that struck me is that the RFC would require the routes to be defined like

{/controller}{/action}{/id}{.type}

which seem that are not very useful for optional parameters like the language. Except thigns like {/path} and {/param,param2,param3} I haven't found anything in the RFC that is helpful for solving the "optional parameters" problem.
Or I haven't properly understood the RFC :)

I do like the fact that the / is included in the parameters because, potentially and with some additional work, one can do a route like so /page{/slug}{-id}{.type} (eg: /page/contact-123.html).

[adrianmiu]

I think it's worth repeating one more thing related to the optional parameters that I've implemented in my code: optional parameters that have the default value are not included when generating the URL. This is very useful for SEO purposes since it will let you make a 301 redirect from /en/controller/action/id to /controller/action/id if the default language is en.

I can't think of a solution to do that if you follow the RFC, even you find a way to use the RFC for matching.

[harikt]

@pmjones this is a long time PR which needs you .

[pmjones]

I'm sorry, man, but after letting this percolate it just doesn't sit well with me, at least not for now.