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.
Related
I am new to ruby on rails and I am working on a web application written by ruby on rails. It has more than 10 models and I need to add some new attributes to some of the models as well as new methods and views. I also will need to remove or enhance some of the functionality. I know that I would need to generate new migrations and from there add/remove new columns. Then in controllers, add/modify methods, and update the views.
I wanted to know what would be the best steps (and in which order) for doing the above tasks. Also, do I need to change other files in folders like test or any other folder? What things should I consider to minimize the troubles later?
Thanks in Advance.
Since you are new to rails, the first thing you should do is to read through the getting started guide. This will help you understand the fundamentals of the rails framework and the application you inherited. After that, there are several other guides worth reading (from the same site) that may be directly applicable to the work you are doing.
Another incredibly helpful resource is railscasts. Some of these are outdated, but they are still a great starting place and can help introduce you to both new, powerful gems and rails techniques to get the work done faster and better.
As to your specific question, rails is built on an MVC architecture (meaning Model Views Controllers). It is in your best interest to try and follow this practice whenever possible. Reading up on this will clarify some of your questions as well.
When you run a migration, you will be modifying your database. The changes are viewable in the database schema (which should never be modified by hand, always modify it through migrations). This will add attributes to your models whose table you modified. In the controllers, you will add logic to deal with all of these things and the views will present the data to your users (or allow users to enter data). Asking which order is best is probably rather opinion based, but I would say you should modify the tables (run needed migrations) first. This way you can then generate the logic to deal with the new attributes. I would then create the controller logic and finally the views.
You also ask what other files need to be changed. This is heavily dependent on your system. At a base level, you should definitely be writing tests to support the logic you are generating (and many developers will advocate that you should do this before you write the other logic, a process called Test Driven Development).
TL;DR: Read the guides, work through a basic tutorial, and watch some Railscasts. This should get you up to speed on the process and best practices that go along with rails development.
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.
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.
I recently started with the 'Agile web development with Rails' book by pragmatic programmers after having some early experience with rails but wanting a more structured approach.
I'm happily following the book when they ask me to make a controller admin so I can edit the standard CRUD product model I already created. According to the book I should add the line 'scaffold :product' to my admin_controller and it should run like a charm. Well, my rails only says: "undefined method `scaffold' for AdminController:Class".
I know he's using an older rails version in the book, like 1.8 or something, and I know how to run a normal scaffold but not how to make the admin_controller inherit all the juicy CRUD details from Product like the books statement suggests. I tried copying all the views and the scaffold generated controller code from the product_controller to admin and that works fine, but I was really wondering what the proper way to do this is.
My admin_controller:
class AdminController < ApplicationController
scaffold:product
end
The functionality you mention, dynamic scaffolding, has been removed in Rails 2.
I recommend using regular scaffolding and going from there if you are new to Rails. Once you get some more experience it will be easy enough to quickly brew your own controller actions.
There are some alternatives to dynamic scaffolding which may be helpful for quick prototyping or if you develop a lot of the similar functionality:
ActiveScaffold
Hobo
The better method nowadays is to use the scaffold generator rather than the scaffold method. The scaffold method was an impressive showcase when rails was first developed, but it hid too much and you couldn't modify just the bits you needed. To solve this, scaffolds were instead done as generators as these expose the code and allow you to edit it more easily. The scaffold method was then removed from Rails to prevent it's use.