EAK: Confusion on code structure


#1

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:

# adapters
# components
# controllers
# helpers
# models
# routes
# styles
# templates
# utils
# views
app.js
index.html
router.js

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?


#2

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).

Here’s the pull request with the details:


#3

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?


#4

I could be wrong, but I don’t think it’s an acronym. I think it’s just referencing a group of entities (route, controller, model) as a “pod”


#5

@jasonmit yeah, I think so too, but I’m curious about the specific meaning :wink:

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.[]'),
...

What’s the purpose of declaring these aliases?


#6

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.


#7

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.


#8

thanks @jasonmit & all the other’s here - you helped me a lot :smile:

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:

# views
|
+# application
|  |
|  + custom-container.js
|  + custom-content.js
+# authentication
|  |
|  + login.js
|  + register.js
|
+ application.js
+ authentication.js

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:

# views
|
+# application
|  |
|  + view.js
|  + custom-container.js
|  + custom-content.js
+# authentication
|  |
|  + view.js
|  + login.js
|  + register.js

#9

I always put my non-standard ember objects in app/libs


#10

@cavneb I put them under app/utils :smile:

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…

app/
  adapters
  components
  controllers
  helpers
  models
  routes
  styles
  templates
  utils
  views/
    application.js
    authentication.js
    application/
      custom-container.js
      custom-content.js
    authentication/
      login.js
      register.js
      register/
        form.js
  app.js
  index.html
  router.js

which seems somewhat weird to me because it’s splitting ‘packages’, if you know what I mean (I hope I can explain myself good enough :smile:)


#11

The PODS format stuff isn’t fully functional (or something is amiss)

The ember-app-kit-todos is missing one thing… the “view”

if you note they have

todos/
   route.js
   template.hbs

and all of that is nice.

you’d then think you could have:

todos/
  route.js
  template.hbs
  view.js

this will break.

You have to have:

todos/
   route.js
   template.hbs
   todos.js

the view name has to match the old-style, even though oddly all the other places you can use generic names and the resolver gets it right.

if you change the todos.js to view.js above, everything will break.


#12

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?


#13

Well, to be clear. Stefan work is amazing and the resolver is amazing. There are just some interesting limitations.

The main one, i’d say in PODS is just the fact that all the filenames have to be the same.

e.g.:

todos/
   template.hbs
   todo/
      template.hbs
      new/
         template.hbs
   index/
      template.hbs

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.