Add controller helpers to auto-generate Locale-prefixed routes

[Bauerpauer]

For example:

class Photos < Harbor::Controller
  localize "en_US", "es", "pt_BR"

  index { ... }
end

def test_auto_generated_localized_routes
  assert_controller_route_matches("GET", "/en_US/photos", Photos, :GET)
  assert_controller_route_matches("GET", "/es/photos", Photos, :GET)
  assert_controller_route_matches("GET", "/pt_BR/photos", Photos, :GET)
end

[fgrehm]

That would be great man, I'd just add that this could also work as well:

assert_controller_route_matches("GET", "/photos", Photos, :GET)

Internally, wherever it is available, the "current locale" would be mapped to the app's default one

[sam]

@fgrehm you mean that in your example, that'd be equivalent to Harbor::Locale::default right? Or do you mean it would depend on Request#locale, which might be default, but might be a requested locale?

I'm a fan of the latter, but I like the generated routes as well since it encourages good SEO.

[fgrehm]

@sam yeah, probably the latter one, the point is that users should not have to type in the locale in order to get to a page, if we don't have that default and they hit /photos they would get a 404 :P

[Bauerpauer]

Ya, I definitely think Request#locale is the way to go.

• Scott

On Mar 3, 2012, at 2:04 PM, Fabio Rehmreply@reply.github.com wrote:

@sam yeah, probably the latter one, the point is that users should not have to type in the locale in order to get to a page, if we don't have that default and they hit /photos they would get a 404 :P

---

Reply to this email directly or view it on GitHub:
#32 (comment)

[sam]

Got it. Well, let's make it so. These helpers seem like a good use of mixins, but I wouldn't want them confused with view helpers so lib/helpers would be a bad place for them. So just modules in the normal structure.

[fgrehm]

Just to be clear about this one and make sure we don't forget, this should probably not register all prefixed routes for all locales, we can just make it make it a wildcard routes like get ":locale/photos" under the hood and simplify the resulting tree or extend the node with a with an "specialized node behavior" like we have when there is a collision between an static and wildcard route while building the tree

[Bauerpauer]

So we'd have a special node in the tree, something like a
"LocaleMatcherNode" for routes that contained the ":locale" wildcard? Only
problem I see w/ that is that the special locale-matcher will be run for
every route w/ a wildcard off the root like that. If you pre-calc the
routes and add "en-US/photos", then the tree would already contain the
information necessary to determine the proper node, or skip it for URL's
that don't use the wildcard.

On Sat, Mar 10, 2012 at 9:45 PM, Fabio Rehm <
reply@reply.github.com

wrote:

Just to be clear about this one and make sure we don't forget, this should
probably not register all prefixed routes for all locales, we can just make
it make it a wildcard routes like get ":locale/photos" under the hood and
simplify the resulting tree or extend the node with a with an "specialized
node behavior" like we have when there is a collision between an static and
wildcard route while building the tree

---

Reply to this email directly or view it on GitHub:
#32 (comment)

[fgrehm]

hum.... I see your point, but wouldn't that make up huge tree if the app has a lot of locales?
maybe we can have something in between, something like the WildcardRoute (check out this issue to see how it works) that would have "root" nodes with available locales pointing to the rest of the tree below that, i'm just not sure about how we would keep track of that when going down the tree:

    pt-BR       en-US    <= this is kinda of a single "node" as well
         \     /
          photos

Maybe having the routes pre-calc'ed is not a big issue from a router perspective (I was able to make it balanced ;-), but if end up providing something like rake routes from Rails, the list will become really big....

Thoughts?

[sam]

Say you've got 500 "base" routes. Then assume each node takes around 1Kb (that seems really high, but that works for the example).

That makes our tree 500Kb. So you enable localization for 20 Locales. That makes the tree 10Mb in size. It makes insertion a lot more expensive probably, but it shouldn't really impact match performance right?

I'm not suggesting that would be ideal, but it seems like a good enough starting point. And we can optimize later in v1.x.

[Bauerpauer]

I can't imagine that we're storing 1k per route, and I doubt insertion time
would take so long as to become a problem, but a benchmark would tell all ;)

-Scott

On Sun, Mar 11, 2012 at 6:51 PM, Sam Smoot <
reply@reply.github.com

wrote:

Say you've got 500 "base" routes. Then assume each node takes around 1Kb
(that seems really high, but that works for the example).

That makes our tree 500Kb. So you enable localization for 20 Locales. That
makes the tree 10Mb in size. It makes insertion a lot more expensive
probably, but it shouldn't really impact match performance right?

I'm not suggesting that would be ideal, but it seems like a good enough
starting point. And we can optimize later in v1.x.

---

Reply to this email directly or view it on GitHub:
#32 (comment)