Pod Syntax

[brendanoh]

Is "Pod Syntax" still on the table and will Ember-CLI support this?

[stefanpenner]

pod syntax should "just work" with the cli, as it is a feature of the resolver.

That being said, the future generators, should likely become aware of this

[brendanoh]

Will we need a new Blueprint for generating Pod Syntax then?

[MajorBreakfast]

The two are interoperable. The non-pod is more straightforward, the pod syntax is what you probably would want to use in a real project. Maybe we should switch. @joefiorini @stefanpenner should we switch? Loom should use the same.

[brendanoh]

FYI - I am at EmberConf at the "Advanced" training day and @wycats seemed to indicate that the Pods structure is the way forward which is why I asked in the first place.

[brendanoh]

I have a rather large personal project I am working on that would be infinitely easier to maintain / browse in Pod syntax. I am 100% for adding Pod syntax support in "new".

[MajorBreakfast]

I know what you mean. Having everything in one folder is a real time saver.

I really like that the blueprint isn't a clean slate but a collection of examples. But maybe it reallly should encourage to use the pod structure.

[Dave-Choi]

Maybe a -p option on new/init/generate?

[MajorBreakfast]

@Dave-Choi For ember generate I think a project setting would come in handy. We still have to think about how we best store these project settings, though. Ideally ember g controller store generates controller:store. If pods are used the file is store/controller.js and if additionally coffeescript is used it's store/controller.coffee

[fsmanuel]

are the eak loom generators pods aware? if not we should start on upstream and then decide how we use them in ember-cli.

[Dave-Choi]

@MajorBreakfast I guess it doesn't belong in the generate, but if you used new -p or init -p, it could just set that project setting as it does the scaffolding.

[joefiorini]

I actually just this week found out that pods are a thing, I'm not sure what the default should be here. @stefanpenner thoughts?

[MajorBreakfast]

new -p or init -p

@Dave-Choi Jep. :) But, I think we should consider making it the default. Stef mentioned previously that we should tack as few options as possible onto new and init.

[stefanpenner]

I think pod format will be part of the generators. Not the init. As an app can easily be pod for some aspects and vanilla for others.

[MajorBreakfast]

@stefanpenner The option is only so that loom generates the file at the right place. If we switch to pods as default, we should modify the blueprint so that it uses pods.

[stefanpenner]

i think the current defaults are fine.

[wycats]

Are they? I thought we had discussed making pods the default.

[stefanpenner]

@wycats the app supports both out of the box, the blueprint itself should likely just be slimmed down and generators can add folders as needed.

[brendanoh]

My confusion was based on whether application route, template, controller
etc is in the current folder format or whether it is in pods as well. If it
is also in pods then we would likely need a -p or similar on Ember new
using a different blueprint. I am going to work on Loom to enable pods as
an optiin and as @stefanpenner said the Resolver will just work.
On Mar 26, 2014 11:09 PM, "Stefan Penner" notifications@github.com wrote:

@wycats https://github.com/wycats the app supports both out of the box,
the blueprint itself should likely just be slimmed down and generators can
add folders as needed.

Reply to this email directly or view it on GitHubhttps://github.com//issues/142#issuecomment-38771952
.

[fsmanuel]

don't forget to add podModulePrefix: '{appname}/{poddir}' in app.js

var App = Ember.Application.extend({
  modulePrefix: 'app', // TODO: loaded via config
  podModulePrefix:  'app/modules'
});