hey,
I thought it was time for me to move on and see what I can achieve if I use the EAK for my further projects. first I wasn’t able to start the plain EAK from it’s current status on my Windows7 machine, so I grabbed the ember-app-kit-todos GitHub project and with this code, I was finally able to run the application.
but, as I checked out the structure of this repository, it seems to me that it’s different to what is suggested in the “main/core” EAK.
In the “main/core” EAK all files are structured to live in folders which represent their “type” as the following folder/code structure is given:
while in the ember-app-kit-todos example, the structure is like this:
# adapters
# components
# helpers
# models
# styles
# todos // <-- Routes/Controllers/Templates all in one place, more namespace-like
+ # active
+ route.js
# completed
+ route.js
# index
+ route.js
template.hbs // <-- resolves to 'todos/index.hbs' ???
# item-controller
+ controller.js // <-- resolves to 'TodosItemController' ???
controller.js // <-- resolves to 'TodosController' (?)
route.js // <-- resolves to 'TodosRoute' (?)
template.hbs // <-- resolves to 'todos.hbs' ???
# utils
# views
app.js
index.html
router.js
so, what’s suggested, common/best practice on code structure when using EAK? are all template.hbs files converted to #folderName#.hbs? so why do components still reside within their own components folder? what about views/utils/models etc?
is anybody currently working with EAK and the latest stable version of Ember (v 1.4.0 at the time of writing) and is willing to give me some advice?
The todos sample app uses the “pod” folder layout. It’s optional and can co-exist with the other folder layout where classes are grouped by function (route, controller, view, etc).
thanks @zackangelo, I read through the pull request, but for god’s sake, what does “POD” mean? “Plain Old Data”, like in POJO (Plain Old Javascript Object)?
so, I can use both and choose what I like best since the ember-jj-abrams-resolver is able to handle both? are there any known “bigger” projects (a little bit more sophisticated than the bloggr or todos example) in the wild so that one can look at their source?
@jasonmit yeah, I think so too, but I’m curious about the specific meaning
Alongside, I saw that in the todos example, Ember specific functions, which are called in any object are declared outside its scope so that they are aliased, like:
// controllers/todos.js
var isEmpty = Ember.isEmpty;
var filterBy = Ember.computed.filterBy;
var notEmpty = Ember.computed.notEmpty;
export default Ember.ArrayController.extend({
active: filterBy('@this', 'isCompleted', false),
completed: filterBy('@this', 'isCompleted', true),
hasCompleted: notEmpty('completed.[]'),
...
This just saves a few characters of typing and makes the code more readable. In the end it’s all wrapped within a function by the ES6 transpiler so they’re not globals.
are there any known “bigger” projects (a little bit more sophisticated
than the bloggr or todos example) in the wild so that one can look at
their source?
You can take a look at one of my open-source projects built on Ember App Kit: Tribute-Web. It is not a ‘big’ project, and in progress, but it is more than trivial.
thanks @jasonmit & all the other’s here - you helped me a lot
but, while using EAK I stumbled upon another “issue” which is nagging inside me and feels like a “bad workaround” for me: let’s say I have an application view and several other views which are also in the application namespace (and the same for a lot of routes), I would have to place my views like this:
so, I would have the “root” view in the “views” folder and all other related views in the corresponding subfolders… is it possible to have a “clean & clear” subfolder structure where the “root” views are also in their respective subfolders, so that it looks like:
what I tried to explain is, that I have to have the following code structure, where the root view is always in the parent folder, instead of it’s own subfolder, where all other views belong…
thanks a lot for the explanation - so PODS is a little bit clearer to me… so the problem with using PODS consistent throughout the whole project lies in the (Stefan Penners ember-jj-abrams-resolver) resolver then?
Everything has the same name! Routes at each level: route.js. Controllers at each level: controller.js etc etc
So once the project get really large… imagine going: “I want to work on template X for something Y… let me open the filename template.hbs (now 70 choices appear and you go try to find the right one)”
etc.
I’d almost say, if the ES6 transpiler is going to spitout AMD syntax anyway… why not then just allow for a requirejs style shim.js to be able to give names for everything so that filename’s done matter so long as they are indexed in the shim file.
