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.
Related
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 have an odd question. Let's assume I create something using scaffolding. This should build me lots of different files including files in the model, view, and controller. I passed it not only the name of the scaffold, but also attributes/fields/variables. When I looked at the model of the scaffold I generated, I don't see those attributes listed. I am puzzled. How does Rails know that a field exists or not? Can I change them in the future to not have a certain attribute or add a new attribute?
I apologize about this question. I am feeling rather overwhelmed by trying to learn this framework. I'm originally a java developer working on small school projects and I want to branch out. I purchased and have been trying to read the Agile Web Development with Rails book that I keep hearing about. It's good, but I'm still feeling rather lost in how everything works. Am I just trying too hard to understand how rails works?
Thank you all!
Scaffolding is a way to generate code, which you will write otherwise. Generated code is only a starting point and not the final version of things.
Model:
When you scaffold, you pass in fields which you need right now. Rails will generate the model and the migration for you. When you run the migration, it will create the table in db with the columns/fields you passed. Model can dynamically determine what are the fields in the table.
If you need to add/remove fields in future, you would need to write another migration to add remove them, which you can do using a rails generate migration
Controller:
Scaffolding generates a standard controller with 7 actions which respond to the restful resource(your model): new, create, edit, update, destroy, show, index. You can add or remove actions as you please. You would need to alter the routes accordingly if you add/remove the actions.
Views:
Rails scaffolding will generate the barebone standard views, with forms for your fields and views to show those fields. You can customize the looks and change the views as per your requirements.
I hope it clarifies things.
Scaffolding is not the only way to generate code. There are generators specific to model, migrations and controllers.
I hope you have read RailsGuides. They are very helpful for beginners as well as people familiar with rails.
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.
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.
I'm new to Ruby on Rails, and I'm trying to create a bass guitar tutor in order to teach myself RoR (and bass guitar). The walkthroughs use Scaffold to create ActiveRecord classes, but they seem to correspond to standalone tables; there's no use of belongs_to or has_many.
I'd like to create three classes: Scale, GuitarString, and Fret. Each Scale has many GuitarStrings, which each have many Frets.
How do I create classes with this relationship using Scaffold? Is there a way to do it in one go, or do I need to create them in an unrelated state using Scaffold, then add the relations by hand? Or should I ditch Scaffold entirely?
I started learning Ruby on Rails a few weeks ago, and I've found it a lot easier to get the hang of things and learn my way around by not using scaffolding, and generating the various parts from the command line (or macros in an IDE).
However, from what I can tell, when you use scaffolding to generate things, you think of it as generating a "resource", so you're only going to create one resource at a time, then add in the relationships by hand later.
However, the generate model command can create these relationships for you. Lets say you used scaffolding to create a Scale resource.
You could then do
ruby script/generate model GuitarString name:string scale:references
The scale:references will create a belongs_to :scale on your GuitarString model, but you'll need to add has_many :guitarstrings to your scale model.
The generate model command also creates a migration script for you and other files needed (fixtures), similar to scaffolding, but doesn't autocreate views or controllers or anything.
EDIT:
This is generally how you are going to want to do things - use the generate/model or generate/view or generate/controller or generate/migration. Most Rails developers don't use scaffolding, since its "one size fits all" rarely fits things perfectly. However, most rails developers do use the generate commands I mentioned - it saves time with creating helpers and fixtures by hand, and it gives each file it generates a basic template you can add to.
Several Ruby IDE's like JetBrain's RubyMine have macros that essentially perform these commands. In RubyMine you can do ctrl+alt+g, then enter another key corresponding to what you want to generate.
The belongs_to relationship can be generated by using the "references" word, as I mentioned. Others you will add in by hand.