-
-
Notifications
You must be signed in to change notification settings - Fork 102
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add POD structure and allow types to have custom prefixes. #16
Add POD structure and allow types to have custom prefixes. #16
Conversation
we should consider how this works with the future PODS idea. |
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... |
let me think it through sometime this weekend. (I'm just mentally toasted right now) |
@stefanpenner - Understood, no problem. For now we will continue to monkey patch in EAKR (so that we can have |
their just appears to be overlap with pods i want to think through. |
Aside from the PODs concern this is 👍 from me |
Updated to address the pod scenarios as explained by @stefanpenner. Also updated description. |
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: ```javascript Resolver.create({ namespace: { modulePrefix: 'app', dogPrefix: 'pets', humanPrefix: 'humans', catPrefix: 'pets' couchPrefix: 'furniture' } }); ``` (Please note all names are real, no making fun...)
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/post/edit/route` * `template:posts/edit` -> `app/pods/post/edit/template` * `controller:posts/edit` -> `app/pods/post/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` ```
@rjackson thx! |
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. |
+1 @wycats i think your idea was good. I like the hybrid approach, support both structures, which will allow composition as needed. |
Add POD structure and allow types to have custom prefixes.
@stefanpenner you made my night 😄 |
@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) |
@ryandjurovich - This is definitely on the roadmap, and is next up conceptually. |
@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. |
@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 :) |
General Lookup Path
podModulePrefix/name/type
modulePrefix/type
(if the format istype:main
)typePrefix/pluralizedtype/name
modulePrefix/pluralizedType/name
So given that I have the following resolver:
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 atpodPrefix/foo/controller
. This format is given the first (and primary) shot at finding a module.For example, given a
podModulePrefix
ofapp/pods
you would have the following:Note that without a
podModulePrefix
set these would all default to themodulePrefix
(basically replaceapp/pods
in the above examples withapp
).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:
And I wanted them to resolve like:
I could do the following:
(Please note all names are real, no making fun...)
This builds off of #14 which adds some real tests.