Controller names

[Morganjackson]

Hi Adam, thanks for this awesome tool!

I noticed that in your example blog you name your controllers Posts.index, Posts.new etc, but the generator now uses PostsController.index, PostsController.new.

Which do you plan to use going forward? is there any benefit of one over the other?

Thanks again!

[AdamBrodzinski]

Hi @Morganjackson, Thanks for reminding me, I forgot to update the examples!

PostsController will be the new syntax. The only benefit would be a more clear description of the namespace and what the method will do (glue between a view and model).

When I first started I wasn't using models (in MVC) and the thought was to have an API that looked like Posts.create, Posts.destroy, etc.. for the controllers. In production my controllers where getting fat and 500+ line controller files were happening on 'God' objects. (User and Posts using the blog example). This syntax became troublesome when abstracting methods into a model because the model was Post and the controller was Posts.

The future of the meteor generate MV*C layout (and what i'm currently using) looks like this, starting from the client template:

(sorry for the lengthy reply, the following is a rough draft for the readme :laughing: )

1. user hits /posts/edit/123 route, PostsController.edit renders the template page to edit the post
2. user fills out form and clicks submit on the edit posts form
3. Template.editPost.events listen and catch form submit, gathers data from form, validates data before submitting, then calls and passes data to the controller. The template JS should really only gather data and send it to the controller Other modules/packages handle validating and displaying errors. Page JS files are just passing the data along, some people call this a view presenter or view controller.
4. PostsController.update calls the Post.update model. If the user needs to know about an error from the model, I handle it here. Analytics tracking usually go here as well. (keeping them out of the view JS keeps things consistent and easily findable).
5. Post.update is a 'model' and it's only job is to save data to the database by calling db.posts.update. This is a great place to add and mixin default data. This is also a good place to do data validation/ user permissions. By putting the db update code here, it allows you to switch databases here and not in the controllers. It also makes it easy to test since it's only doing 1 thing.
6. db.posts is a thin wrapper for mongo collections. This gives it the same API as the mongo console. The model calls db.posts.update(idParam, '$set': someData); and the data is saved.

I'm not 100% sure if the best way to go is to use the built in collection.update method or to manually create it using a meteor methods and stubs... i've done both in production and the latter gives you a lot of flexibility but costs more in boilerplate and complexity.

While the above may seem like overkill at first, when I started out I naively made db.posts.update calls in the event listeners. Those files grew bloated and suffered from duplication. They were next to impossible to test.

Hope this helps! I'll try and get the examples cleaned up this weekend (and perhaps push the collections branch).

[AdamBrodzinski]

also on the back burner is collections, models, config file, user templates to customize your setup, coffeescript/es-next support, and automatically scaffold tests.

[Morganjackson]

Thanks for the detailed reply!