Add POD structure and allow types to have custom prefixes.

[rwjblue]

General Lookup Path

• podModulePrefix/name/type
• modulePrefix/type (if the format is type:main)
• typePrefix/pluralizedtype/name
• modulePrefix/pluralizedType/name

So given that I have the following resolver:

Resolver.create({
  namespace: {
    modulePrefix: 'app',
    podModulePrefix: 'app/pods',
    petPrefix: 'animals'
  }
});

The lookups would be like the following:

• fruit:orange
  • app/pods/orange/fruit
  • app/fruits/orange
• pet:dog
  • app/pods/dog/pet
  • animals/pets/dog
• furniture:main
  • app/pods/main/furniture
  • app/furniture
  • app/furnitures/main

POD Structure

When given an item to lookup (say resolve('controller:foo')), the POD structure would dictate that you would actually be looking up a module at podPrefix/foo/controller. This format is given the first (and primary) shot at finding a module.

For example, given a podModulePrefix of app/pods you would have the following:

* `route:posts`            -> `app/pods/posts/route`
* `template:posts`         -> `app/pods/posts/template`
* `controller:posts`       -> `app/pods/posts/controller`
* `route:posts/index`      -> `app/pods/posts/index/route`
* `template:posts/index`   -> `app/pods/posts/index/template`
* `controller:posts/index` -> `app/pods/posts/index/controller`
* `route:posts/edit`       -> `app/pods/posts/edit/route`
* `template:posts/edit`    -> `app/pods/posts/edit/template`
* `controller:posts/edit`  -> `app/pods/posts/edit/controller`
* `route:posts/show`       -> `app/pods/posts/show/route`
* `template:posts/show`    -> `app/pods/posts/show/template`
* `controller:posts/show`  -> `app/pods/posts/show/controller`

Note that without a podModulePrefix set these would all default to the modulePrefix (basically replace app/pods in the above examples with app).

Custom Type Prefixes

If a module was not found via the POD lookup structure, look for a custom typePrefix value on the namespace.

This allows us to customize where each type is looked up.

For example if I have the following types:

• human
• dog
• cat
• couch

And I wanted them to resolve like:

• human named 'Rob' - 'humans/rob'
• dog named 'Lucy' - 'pets/dogs/lucy'
• cat named 'Kisses' - 'pets/cats/kisses'
• couch named 'Ethel' - 'furniture/couches/ethel'
• EVERYTHING else under 'app/'

I could do the following:

Resolver.create({
  namespace: {
    modulePrefix: 'app',
    dogPrefix: 'pets',
    humanPrefix: 'humans',
    catPrefix: 'pets'
    couchPrefix: 'furniture'
  }
});

(Please note all names are real, no making fun...)

---

This builds off of #14 which adds some real tests.

[stefanpenner]

we should consider how this works with the future PODS idea.

[rwjblue]

I do not perceive that this is opposed to the pods concept, but will need to think through how the resolver will know what "thing" is in "which" pod.

Hopefully, that is not a blocker for this though...

[stefanpenner]

let me think it through sometime this weekend. (I'm just mentally toasted right now)

[rwjblue]

@stefanpenner - Understood, no problem.

For now we will continue to monkey patch in EAKR (so that we can have config/router, and config/adapter).

[stefanpenner]

their just appears to be overlap with pods i want to think through.

[bcardarella]

Aside from the PODs concern this is 👍 from me

[rwjblue]

Updated to address the pod scenarios as explained by @stefanpenner. Also updated description.

[wycats]

A pod is born.

[fsmanuel]

@rjackson thx!

[rwjblue]

As an example of using this new pod structure, I have created stefanpenner/ember-app-kit-todos#11 which utilizes this fork/branch of the resolver and demonstrates the folder structure that is possible.

I honestly, quite like the result with the exception of some small oddness with item controllers (small issue).

Also, just to confirm, the tests (and the application) work as it was originally AND after the refactor. This proves that you can opt-in to pods for certain things, and allow the resolver to fall back to the "standard" structure for other things.

[stefanpenner]

+1 @wycats i think your idea was good. I like the hybrid approach, support both structures, which will allow composition as needed.

[wycats]

@stefanpenner you made my night 😄

[ryan0x44]

@stefanpenner this is awesome! Is there any way to use this and have some of the pods placed in my vendors folder? (so I can pull them in through bower)

[rwjblue]

@ryandjurovich - This is definitely on the roadmap, and is next up conceptually.

[stefanpenner]

@ryandjurovich yes, @rjackson and myself had a great phone call this afternoon to talk about an initial implementation. We believe the vendor lookup problem is related to pods, but will likely involve (re)introducing the namespace concept.

[ryan0x44]

@rjackson @stefanpenner that's great to hear! I'm working on a new open source project at the moment that will really benefit from this, so I'm definitely looking forward to it :)