Implement interface separation between general and organization-specific routes

[begedin]

NOTE: This branches off of #7 so it contains changes from there as well.

This is an attempt to create interface separation between general and organization-specific routes. It works, sort of, but I don't like the way I achieved it. I pushed the changes up here so we can discuss ideas for potential alternatives.

Assumption

• We want two basic access URLs
  • [www].teamplaybook.com
  • organization.teamplaybook.com
• If we open the first URL, we get the general site interface (register/login, create new organization, access specific orgazation, etc.)
• If we open the second URL, we get the organization-specific interface (login, organization resources such as messages in slack, etc.)

  Problem

The following doesn't work:

export default Router.map(function () {
  this.route('login');
  this.resource('organization', { path: '/' });
  this.route('some_general_route', { path: '/' });
});

That is, it works, but if we want to access the general route, it will still attempt to access the organization resource and try to load a model.

Basically, I don't think we can have routing to two different things on the same route URL. To Ember, domain.com/ and subdomain.domain.com are the same resource/route.

Solution

The currently implemented solution (which I really dislike) is the following:

• application route model hook loads the organization if we have a subdomain, returns null otherwise.
• application controller has a flag indicating if organization is being accessed
• application template has an {{#if}} helper and renders a different template (with a different controller) based on the controller flag
• biggest issue with this solution - The organization template has a named outlet. Each organization-related route needs to use the renderTemplate hook to render into that specific outlet. Otherwise, it isn't rendered.

  Other attempted solutions

• Have two resources with the same path, but different names (organization, general) and subroutes. - This would be the cleanest, but the router gets confused and throws errors.
• Get rid of the {{#if}} helper and handle what and how it renders in the route logic - Doesn't really change anything, just moves the complexity to another spot.
• All routes are root routes, each responsible to load their own model - Get's more difficult to manage as the number of routes grows, but is the simplest and cleanest to implement at the moment. We will have to load the organization for each organization route, though, and we lose the advantage of grouping files under resources.

  Ideal solution

In my opinion, the ideal solution and one we should spend at least some time exploring would be to modify the default ember router so it works for our specific case of having two resources ("organization" and "general") under the same path "/". If we only ever access links via the resource.route reference and not via the path reference, I don't think having them on the same URL path would be an issue.

I'm not sure if that solution is possible, though.

[venkatd]

It may best to check window.location.host to add this check at a lower level.

http://stackoverflow.com/questions/18262215/ember-js-rails-and-wildcard-subdomains

We can have two routers OrganizationRouter and DefaultRouter. Then we can export the proper one depending on this check. Thoughts?

[begedin]

@venkatd: That seems like the most straightforward approach. I tried looking into actually customizing the default router (.reopenClass, .extend), but the actual routing is highly encapsulated so I don't think it was intended for us to customize it.

[begedin]

@venkatd For an update, I ended up doing something similar to what you suggested. The only thing is, we don't export the Router in router.js. We export the result of a Router.map(callback) call. Since some routes will be common to both sides of the app (login route, for instance), I ended up doing a logical flag check within the Router.map callback and it's at that point that the route definition splits.

Because of that and the fact that ember-cli-subdomain only works as something you inject into various parts of the app, I had to implement my own url-info library and abandon the ember-cli-subdomain add-on. Looking at the code of the add-on, though, the logic I'm using is nearly identical. It's not actually something very complex.

[begedin]

I believe this is now at a point where it should be mergable. Next up, we either start hooking this up to the actual API, or I can start working on the actual interface, depending on which comes sooner.