CRUD idea

[scottmcpherson]

Today I had to create a blog for my soon-to-launch startup, and one thing that was kind tedious was to create all of the admin CRUD functionality for the blog. In other words, creating a table view to list all blog posts, a form view to add and edit posts, and the methods and all of the check() functions. When using em, I though it would be kind of nice to either have an additional argument that you could pass in when executing the scaffold command:

~$ em g:scaffold:crud --fields="name:String, isVisible: Boolean, etc.."  

or it could just be an entirely separate generator:

~$ em g:crud --fields="name:String, isVisible: Boolean, etc.."  

I'd be happy to fork this and submit a pull request if you think this could be useful. What do you think?

[cedricmay]

This would be a (logic) level higher than what em is right now.

I'm experienced with rails and I rarely use scaffolding simply because my end goal is far from simple CRUD actions. However, there's no strict rule to not use scaffolding. Some coders frown on it because it is actually scaffolding, literally. It's not a finished product. – via Stackoverflow: Why do Ruby on Rails professionals NOT use Scaffolding?

I would like to have something like this, too. Maybe it could use something like Meteor Autoform and Simple Schema. The list view could use this schema as well to show all available fields, or maybe add an option to the schema for visibility of fields in table / detail view?

I think this would be a nice external package to em:

cmather: I would also love to see the ability to use packages to extend the em command line tool, either with additional project layouts or other useful sub commands. But I admit this is a bit trickier :). It's on my list of things to investigate. https://github.com/EventedMind/em/issues/6#issuecomment-40881573

[teonimesic]

I am a Rails Developer (7 years now, since Rails 1.21) and i do use scaffolding frequently. Firstly, because i care a lot more about back end logic than I do front end. I usually leave the html scaffolded as is, since a designer is probably gonna change everything anyway. But I do like that it generates a basic controller for me, which really doesn't changes much (at least as far as CRUD goes). It also generates some tests, and this is probably THE best feature of the rails scaffolder. It makes it super duper easy to write tests, because they are already there and working, and there are even a lot of examples in the tests/specs folder for you to guide yourself. This is something quite important to add, because without it every time you scaffold anything you would have less test coverage until you added them manually.

Another cool thing about rails's scaffolding is that you can customize its templates. So a designer could go ahead and create your CRUD templates before you scaffold anything, and then when you do there will be fewer changes to be made.

I would really love a CRUD scaffold feature, not only for speeding development time (at least for prototypes), but also because they help new developers to understand how to do a basic CRUD in the meteor framework the "standard" or "popular" way. Since meteor doesn't enforces anything the way Rails does, every project has different folder structures and code conventions, which is not a good thing.

[benstr]

+1