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.
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've finally started making a Rails app from scratch and I'm getting the hang of it, but the only problem is that making all the models/controllers is getting really repetitive and totally throwing the whole DRY concept out of the window as I'm basically copying controllers and renaming them/adding/disabling fields. I have:
Projects
People
Tasks
Messages
etc and the first three need to pretty much have the same layout and CRUD. Is the only way of not having to manually create all of the actions/views each time scaffolding? If so, what other things does scaffolding generate that I need to be aware of. I've been cautious of using it in the past because I wanted to know how my application worked in the tutorials.
In my opinion scaffolding is not for new rails programmers, it should only be used after you figured out rails yourself and with a criticizing approach. It may generate whole files that you have no need, define unneeded routes etc...
You can have a look at the full details of what scaffold creates here
As for the repetitive controllers you are making I could suggest using the gem InheritedResources which eliminates a lot of this duplication (at least while you are at the basic CRUD controller operations)
InheritedResources sets the basic controller index/show/destroy/create/edit actions for you, all you have to do is to inherit from it using:
class ProjectsController < InheritedResources::Base
end
In case you have to, you can override actions by defining them yourself.
It's an excellent point. You generally want to keep your controllers as thin as possible, and certainly thinner than what the scaffolding gives you.
The way I like to think of the scaffolding is that it's good to use for your first feature in a new Rails app as an example of the current best practices and things you might want to know about. After that, however, write your controllers yourself, and factor out any duplication.
For additional ideas, you might want to read/watch...
Objects on Rails
Hexagonal Rails
Architecture the Lost Years
Just learning rails, developing first app and having trouble finding a straight answer to this question!
I want to keep my models as lean as possible and really only want to use them to represent objects that I might want to render in my views. Therefore, I want to remove some of the logic from one particular model and store it in a separate file. I have seen numerous guides (on this site and others) that suggest the following;
never "require" anything from inside a rails app
Store additional files in the lib folder - they used to be auto loaded in older rails releases but now you need to add an extra line in a config file to get this to happen (Example.
So I added the line, stuck the file in the lib folder, and it all worked fine. So on to the question;
I can't shake the feeling that the fact that I had to go and put some bespoke code into the config file means I'm doing this wrong (given convention over configuration). Why are people having to faff around editing configuration files to get rails to do something so basic?
Is that the best way or are there additional considerations that I'm just not seeing? Should I in fact be creating an "extras" directory rather than still sticking things in lib?
If anyone can point me in the direction of a definitive article on the matter I'd be much obliged!
There is nothing wrong with having non active record models in the model folder. If your domain is best modeled by a business logic layer and a persistence layer, then model it that way in your model folder with appropriate naming conventions. Personally I wouldn't be overly concerned with getting it perfect. Try something and see how you like it.. learn from your mistakes and keep getting better! Above all, enjoy the process.
what I do is this: keep the model logic in the model and keep the controllers as thin as possible
If there are things that should belong to your model but are somewhat distant to it (for example you have an Account model and you're working on some payments system which relates to the Account - for example you might want to call account.has_subscription?, you could use a gem called concerned_with which would split your model's main actions from others like the ones handling payments (this is just an example I recently had to take care of).
I have been spending some time creating what I called a framework.
It was aimed at the creation of quiz likes games. It was supposed to have two players syncronized and present them a question to solve, etc.
I would like it to be fully customizable so I tried to develop components that can be put in or out of the pages. In the end the elements became slim ruby methods to add a whole bunch of Javascript and CSS to the pages.
Still the Javascript needs to connect to Ruby so methods supporting it are created but they will only be present when the component is present. Some components depend on one another making everything overly complex.
And after this attempt I wonder, is there is not a better and easier way to make a framework aimed to one kind of application on RoR? Or is the concept flawed or RoR in some way flawed?
Ruby on Rails is a framework on its own accord and is "opinionated software". This means that the writers of Rails looked at what would make most sense for creating a web application to them. Many people support the original developers views and so use Rails for their projects as well.
I think your concept of creating a quiz is a good one, but first you need to understand the rails stack. Depending on what you need exactly, you can create either an engine, plugin or whatever.
What I have seen a lot is that you specify what you need in your controller. (How you do that is up to you). All that information is stored in a class variable and transferred to the view where you can render everything you need with some helpers. The hard part is making it all generic enough to be reusable.
But, maybe Rails isn't the right tool for you. Maybe you need something more lightweight like Merb or even Sinatra.
There is no 'flaw' in Rails. Rails is not the 10**1000-in-one tool Java is. It's a framework that tries to do one way very good in a particular way. I think Rails can be the right tool for you, but you need to be skilled enough to wield the tool :)
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.