This is the reference point. All the other options are based off this.
|-- app
| |-- controllers
| | |-- admin
| | | |-- postsController.js
| | | `-- usersController.js
| | |-- postsController.js
| | |-- sessionsController.js
| | `-- usersController.js
| |-- models
| | |-- post.js
| | `-- user.js
| |-- views
| | |-- admin
| | | `-- posts
| | | |-- edit.jade
| | | |-- index.jade
| | | |-- new.jade
| | |-- layouts
| | | `-- application.jade
| | `-- posts
| | |-- index.jade
| | `-- show.jade
| `-- helpers
| |-- admin
| | |-- postsHelper.js
| | `-- tagsHelper.js
| `-- postsHelper.js
`-- config
| |-- application.js
| |-- locale
| `-- en.js
| |-- routes.js
`-- lib
`-- spec
| |-- helper.js
| |-- models
| | |-- postSpec.js
| | |-- userSpec.js
| `-- acceptance
| |-- loginSpec.js
| |-- signupSpec.js
| `-- postsSpec.js
`-- vendor
| |-- javascripts
| | |-- jquery.js
| | |-- underscore.js
| `-- stylesheets
| `-- prettyPhoto.css
|-- app
| |-- controllers
| |-- models
| |-- views
| `-- browser
| |-- controllers
| |-- models
| |-- views
| `-- mobile
| |-- controllers
| |-- models
| |-- views
`-- config
`-- lib
`-- spec
`-- vendor
Pros:
- lends itself great to progressive enhancement so-to-speak. You start with just
/app
, and if your app starts growing, you add sub directories. - doesn't pollute the top-level directories, which have a pretty uniform convention across apps. However, people do add
/themes
to the top level, which is just about the same as adding/client
to the top-level.
Cons:
- Now you have
/app/models
and/app/browser
, etc., which isn't a totally clear naming convention --/app/models
is for a subset of code for the server, while/app/browser
is a totally different app. It's different than a namespace like/app/models/admin
though, which makes sense.
My vote: no
|-- app
| |-- controllers
| |-- models
| |-- views
| `-- client
| `-- browser
| |-- controllers
| |-- models
| |-- views
| `-- mobile
| |-- controllers
| |-- models
| |-- views
`-- config
`-- lib
`-- spec
`-- vendor
Pros:
- The main reason you need these extra folders is for the different clients for the app. So putting them in
/app/client
conceptually makes a lot of sense. It's easy to reason about. - Similar to Rails, which has
/app/assets/javascripts
instead of/app/client
. You don't want to start naming the folder/app/assets
because, conceptually, everything is JavaScript, and calling one chunk of JavaScript "assets" and the rest "app" is conceptually jarring.
Cons:
- You have deeply nested folders for core code, which can be annoying.
/app/client/browser/controllers/postsController.js
is 4 folders down. But with TextMate and CMD+T, it shouldn't be an issue.
You could also have this structure if you only had 1 client (or just a default client):
|-- app
| |-- controllers
| |-- models
| |-- views
| `-- client
| |-- controllers
| |-- models
| `-- views
That's pretty clear, and it lends itself to agile development really well.
My vote: ✔
|-- app
| |-- controllers
| |-- models
| |-- views
|-- browser
| |-- controllers
| |-- models
| |-- views
|-- mobile
| |-- controllers
| |-- models
| |-- views
`-- config
`-- lib
`-- spec
`-- vendor
Pros:
- Minimum folder nesting
- model/view/controller folders are all at the same level
Cons:
- Having multiple top-level folders, all of which are mvc code, is not conceptually clear. They should be part of one directory (taking us back to #2). Having every folder at the top level be a completely conceptually distinct part of the app (database vs. app vs. config vs. tests) is a clarifying convention.
My vote: second choice, but no
|-- app
| `-- client
| |-- controllers
| |-- models
| |-- views
| `-- mobile
| |-- controllers
| |-- models
| |-- views
| `-- server
| |-- controllers
| |-- models
| |-- views
`-- config
`-- lib
`-- spec
`-- vendor
Pros:
- Clear, normalized separation of concerns. Everything fits into the same folder structure, instead of having the "default" stuff in
/app
, and then also nesting components in there.
Cons:
- For the simple case, you have to create a nested folder.
- Counterargument: But, you're setup to easily add other clients for the app
- By not having the default code go in the top level
/app
, it's not as clear thatserver
code can be used on the client (e.g. using/app/server/models/user.js
on the client. it makes sense if it's in/app/models/user.js
however.).
My vote: no
This breaks convention, but it's an option. Rename /app
to /server
|-- client
| |-- controllers
| |-- models
| |-- views
|-- server
| |-- controllers
| |-- models
| |-- views
`-- config
`-- lib
`-- spec
`-- vendor
Pros:
- Clear: there is a client and server app.
Cons:
- If you had multiple client apps (browser, mobile, ipad, etc.), you'd end up doing things like #2 or #3.
My vote: no
I prefer folder structure #2.
Yes regarding multisites, I agree it would be much more advanced. And I can easily see not wanting to include it because of that. In my last comment I was mainly discussing what others are doing and how the similar * could * be done in tower if it was decided to do so. Realistically, a multisite system would probably be more along the lines of something a cms or other system would do to build on top of this (this is also something I am trying to build myself. it is part of a requirement for an app I am building where multiple sites will share much of the same server side code and each site will have a different subset of functionality).
Plugins, yes these would ideally be npm modules that are made to be compatible with whatever system is built. Since the platform I am making will have a simple core and have its own plugins to enhance it, which will be either included with the core and enabled by a setting, or installable from npm. I think the key there is to keep the node/npm standards and make everything follow what people are familiar with.
uploads, database, etc could all be configured by a config/datasources/coffee file. In there you would define and source to save or pull data from. You can define that you shall either use uploads, json files, amazon s3, rackspace files (which on a rackspace server you can tie to a local directory i believe on a VPS), or whatever you want. those other options could each be an npm module defining how to connect and uses the api, and in the datasources.coffee file you would tell your app about that datasource module, and its credentials to pull/save data from/to it. Also this would obsolete the databases.coffee file since they would be defined as a data source, which is kinda what it is.
When you have a model, by default they use your default data source (usually mongo), but you could also have a datasources variable that would define what sources it uses. For example, User model could have something like
and a page model:
an file/upload model:
I think behaviours/components would be great too. there tends to be code commonly shared between some models/controllers.
Yea I agree widgets could be optional too. But to me, a widget really would just be a special way to use a template. and anything beyond that would be up to the user to define, unless there is something that would be beneficial to have in core.