URL generation works for more complex routings as well. For example, therouting for our blog includes the following mappings.map.connect "blog/:year/:month/:day",:controller => "blog",:action => "show_date",:requirements => { :year => /(19|20)\d\d/,:month => /[01]?\d/,:day => /[0-3]?\d/},:day => nil, # optional:month => nil # optionalmap.connect "blog/show/:id",:controller => "blog",:action => "show",:id => /\d+/ # must be numericmap.connect "blog/:controller/:action/:id"Imagine the incoming request was http://pragprog.com/blog/2005/4/15. Thiswill have been mapped to the show_date action of the Blog controller bythe first rule. Lets see what various url_for( ) calls will generate in thesecircumstances.If we ask for a URL for a different day, the mapping call will take the valuesfrom the incoming request as defaults, changing just the day parameter.url_for(:day => "25")#=> http://pragprog.com/blog/2005/4/25Now lets see what happens if we instead give it just a year.url_for(:year => "2004")#=> http://pragprog.com/blog/2004Thats pretty smart. The mapping code assumes that URLs represent ahierarchy of values.2 Once we change something away from the default atone level in that hierarchy, it stops supplying defaults for the lower levels.This is reasonable: the lower-level parameters really make sense only inthe context of the higher level ones, so changing away from the default