I created, using the scaffolding, a model and controller files.
Later I discovered it would be a good idea to create the tables in the DB first...
My question, How can I role back the generated files and regenerate them now, that I have the tables in the DB?
I just started learning RoR, so right now I am not interested in best practices, just learning the tool box this FW (RoR) comes with.
And, do you have a recommendation for a good tutorial? I do know to use google, it is just that search engines don't know, yet (working on that), how to grade tutorials.
Edit: For my last question I found Learning Ruby on Rails
try
rails destroy scaffold XXXXX
one thing that I find puzzling though is that you said "Later I discovered it would be a good idea to create the tables in the DB first..."
Well, rails creates a migration file for you when you run the generator in the first place, and this file will create your DB tables and fields when you run it using rake db:migrate
PS - here's a few good tutorials for you:
rails tutorial ebook
rails demo site
rails 4 zombies
You can rollback controller.
rails destroy controller [controller]
You can delete all the files Rails created -- just look at the printout on your command line, see what files rails created, and delete them.
I don't know why you would want to create all the tables in the db, but that's fine, I guess. I prefer to let rails do it. Either way, Rails won't mind. You can always add / change fields using Rails, even if you created the tables outside Rails.
Ryan Bates' Railscasts are excellent tutorials.
Related
I'm new in Ruby on Rails, I'm wondering, is there a user interface to see all the data that you have in your Active Record Models and manipulate them just like PhpMyAdmin?
Sadly no - you have to write that interface yourself... :)
There are ways to quickly scaffold up an interface for each of your models. Look at doco on rails generate scaffold for more info.
There are also gems that will automate some admin-scaffolding for you:
Look at eg ActiveAdmin
But in practice nobody keeps either of these around for long in their projects (for various reasons).
If you're new to Rails, I can highly recommend reading your way through the Rails Guides here: http://guides.rubyonrails.org It will help you level up in all the fundamental aspects of Rails :)
There are gems in rails to maintain tables in rails app:
ActiveAdmin: It provides admin panel using which you can add/update/delete any record under tables.
rails_db_info: Just and it under Gemfile and run bundle install. Go to "/rails/info/db" link, it will list all tables with schema details. Its very easy to integrate.
I'm a PHP developer, and any framework I've used, scaffold is recommended just for tests.
So, my question is: in Rails too?
It's recommend use scaffold in production (for just a CRUD, example: a blog)
Because, on thing is different: in some PHP frameworks, the scaffold views is processed/created in each requisition, but in Rails (I think), the files are already created.
Scaffolding is kind of standard structure of Rails app. As ruby is a deadly flexible language, I think Rails implements this feature just to guide new comers to make things work in a relatively uniform way.
Anyway, it follows the best practice of RESTful pattern. Although we won't always use "rails g scaffold xxx...", the main file structure of the program is just like the scaffold.
PS: for some situations like building the platform for admin, scaffold is really a good tool to use. Because the standard table, the CRUD actions are just admin's daily work. Scaffold saves days on this kind of stuff.
You need to be aware that if you generate a Rails scaffold for a model, it'll generate all the code required to create, read, update and delete (CRUD) stuff in your database. You probably don't want that kind of priviledge given over to all users in a production environment (particularly update and delete) so that's why it's dangerous to blindly upload scaffold code to production.
If you do create a scaffold, you should go through it and remove all the parts you don't want to be exposed in a production environment. For a simple blog, you probably only want the index and show functions and remove the ability to create, update and destroy entries (or at least protect them with some authentication solution so that only you can do that).
I would say that the code generated by a scaffold is fine to use in production, it's more that you need to be careful what priviledges you give to public users.
If nothing else, scaffolds are very good for learning about how database driven applications work.
Depending on the situation, I do scaffold my models when I generate them and then remove stuff I don't need and tailor it to my requirements (including adding tests). I usually find that quicker than writing all the code from scratch (especially when it generates the database migration file, test files and adds the model resource to the routes file at the same time).
Most developers do not use the scaffolding.
It's not the worst thing in the world, but it will give you a generic, out-of-the-box setup. I personally think it's best to avoid when you're just starting out because then you won't learn the basics very well. And it's best to avoid when you're more skilled because it probably won't give you what you want anyway.
I'm new in the world of Ruby on Rails. I have some problems to solve before start to build a store-like web application.
I'm following instructions written in the book "Agile Web Development with Rails" so I decided to use sqlite too...
...but I have already represented the scenario via ER Diagrams and now I don't know how to bring it on rails.
In the early chapters of the book, it uses the scaffold command to create the table "Product". But this command creates model, view, controller and test for every table I want to represent.
Is it the right way to proceed? Or is there a way to build all my tables before I start to create mvc I need?
Try the Guides to Ruby On Rails:
http://guides.rubyonrails.org/getting_started.html
It's generally easier to understand (in my opinion) than the Agile book.
The easiest way to create your tables is by using Rails migrations.
The easiest way to create migrations with the related models, views, and controllers is:
rails generate scaffold Product
That command will print what it's doing. Take a look in those files.
If you have many tables, yes the typical way is to generate many scaffolds, for example:
rails generate scaffold User
rails generate scaffold Product
rails generate scaffold Company
rails generate scaffold Invoice
...
In your comment you ask about a type_of_product table. For tables like these, yes it's fine to skip the scaffold (for example because you don't need a controller) and instead just generate a migration:
rails generate migration TypeOfProduct
Heads up that Rails does odd things with the word "type". When I did a table like that, I found it easier to start with the main word then use the word "kind" like this:
rails generate migration ProductKind
Short answer: YES, this is the right way.
Longer answer: Usually you want to design a model, then design the next one, so usually this is the right way. If you create a table without a model, there is no value in pure existence of a table.
If you want to create only tables, without a model, you may create migration. Just use ./script/rails generate migration CreateSomeTable.
In any case you may just ignore the created files which you do not need right now. Just let them stay where they are, and focus on all the tables (migrations) if you wish so.
Scaffolding gives you a great starting point for working with a resource, such as a user, post, article, etc. It generates models, views and controllers and then you can focus on modifying it to fit your needs.
Your entity relationship diagram gives you a great roadmap for building your system. You shouldn't be worrying about big banging 20 tables into the app at once. You should, instead, build them out one and a time (through scaffolding or the other rails generators for models and migrations) working on them until they are right, then building out the other tables and relationships one at a time.
Work small and you'll be incredibly productive. Work large and you'll spend a lot of wasted time trying to figure out where you went wrong in a single giant operation.
First and foremost, I am brand new to Ruby on Rails and very rusty when it comes to programming. I have done some research but I am still trying to learn the basic inner workings of RoR. I have completed the Ruby on Rails Tutorial by MHartl.
What I am attempting to do to expand my knowledge of Ruby on Rails is to add a comment function to the Microposts. I have tried to simply add a comment column into the db and then work it into the already functioning microposts. I have also tried to generate a new model called commments using the following line:
rails generate model Comment content:string user_id:integer micropost_id:integer
I think I may have been on to something with that last one but I am hitting a road block when it comes to implementing it. Can someone please point me in the right direction?
You may want to look into Rails associations between models which allow you to associate one record to others. I would recommend looking over the following resources:
A Guide to Active Record Associations
Cardinality and associations
ActiveRecord::Associations::ClassMethods
Your close and I think that looking through the Rails Guide will get you up to speed on what types of relations you want to define. If you need more hints just ask.
In Symfony i just have to create models with ORM Designer and export it to symfony as a schema.yml and then use a symfony command to create tables, models and forms.
I wonder if there is an equivalent to the RoR so that you dont have to create models manually by hand?
It saves a lot of time using GUI for this kind of tasks and it is less error-prone.
thanks
it should be possible to support RoR in ORM Designer. The trouble is that we know only PHP and wouldn't be able to beta test RoR support and create unit tests. But if there is anybody willing to help, please let us know at support at orm-designer dot com and RoR support can be released within a few months.
You can use the model generator with script/generate model to create a model class and migration. A great reference on migrations is cheat migrations which is available via the cheat command.
You could use the scaffold generator as per Getting Started with Rails, however scaffolds are "considered harmful" by many (including myself). I prefer to generate an initial migration with script/generate migration, tweak it to suit and then create/update my model, routes, controllers and views manually.
If you are still starting out, you will probably find it helpful to run through Getting Started with Rails at least once.