Is it possible to build two scaffolds independently and then add active record associations to them from scratch? Finding it difficult to find a solution on line that does it this way.
Thanks
Scaffold simply "dumps" code into your project, you can/should edit it later. The templates scaffolding use, are not meant to create production apps, rather a jump start, specially for new developers.
If you want to re-run scaffold you can do so, and the generator will ask you to override files or not.
Related
Are there any parameters to pass to rails new <app_name> so new app will not have a lot of comments in generated files? Or maybe there is some other way to delete all those comments automatically?
There is no way to create the rails app without comments
Actually it is a good practice to have the comments, and then you can delete them one by one if you want
The Rails app generator does not have an option to remove comments. The comments themselves are part of the code templates which the generator uses to generate the files like config/application.rb.
Rails does let you setup your own application templates and generators which could be used to this end but its a large and not very worthwhile endeavour. Comments are actually very helpful when you introduce new members to a team or just forget what a configuration option does.
Or maybe there is some other way to delete all those comments automatically?
That leaves options like grep which could be used to search and delete lines starting with #. But again the comments are actually helpful and there are better things to spend your time on.
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 love scaffolding and it extremely helpful for prototyping. But Should we use scaffolding for developing application as such?
The name "scaffolding" is sort of a misnomer in Rails now (post 2.0). The structure generated through scaffolding generator is more of a base application to build on, rather than a "prototype" that you throw away later.
At least, if you are designing your application to be RESTful, you will find yourself keeping most of the scaffold generator produced controller and model code, while adding more logic to them. You will perhaps replace the views eventually while keeping bits and pieces of Ruby code in them.
There is no harm in using scaffold to kick-start development of your application. However, if you are a newbie you need to understand how stuff can be done without it. Scaffold is a tool for rapid prototype development in rails and can be used if you can alter it to suit your requirements quickly.
i use it a lot
i strt off with scaffolding and then gradually replace it with custom code; it's a great way to get something up and running pretty quick.
Actually It's depends on your requirements. When we consider about the scaffold it will generate CRUD(Create, Read, Update and Delete) operations instantly. So if you need to remove some of operations its really easy if you coded it manually. But that also can be done by using scaffold also. Just you have to remove those methods only.
So it's your choice whether you use it or not
I have read some books,the author all told me that a for developer will not use it in they business project.So I am not using it in my project any time.But it is only my options,it is up to you.