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.
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'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
on the last projects i've started, I wondered if I should use the admin generator or not. My usual choice is to not use it, as some developers suggested to me, "unless it's for quick backend prototyping and submission to client", they said. Currently i'm starting a project and i'm in the situation that the client need the backend very fast to start loading lots of data, and i'm doubting about using the admin generator or not. I would use it if needed simple form fields. But one of my models must have multiple images, and maybe I need a more complex view that allow the client to load N images, so the admin generator maybe it's not the best choice, but it seems fast, it seems to save time and that's what I need now, time saving!
The project is very simple, it's just a Product model with multiple images and multiple sizes and belongs to a simple category.
What do you think? What would be the best option for this? And where do you think that makes sense to use the admin generator or the regular module generator?
Thanks in advance!
Regards.
I use the admin generator as much as possible. It is really designed to be great for the "backend" of your website-- the administrative screens which authors and editors will use to maintain the app. Any module that needs to be user-editable and is simple cries out for the admin generator.
Recently I have been starting everything with the admin generator so that there's a working prototype to build data with. Then I select certain modules or views that need more magic sauce, and build them out with more customization.
Remember, you can add views and forms to an admin generator module. On my last project I used the admin generator for the "edit" action of my main object but added "show" methods similar to a non-admin-generator form-- adding an executeShow() action and showSuccess template.
The other thing to keep in mind is that the admin generator is only a generator. It writes a bunch of code for you in cache/frontend/env/modules, but you can override any of it by building the equivalent code in apps/frontend/modules/. If you find one part of it that you can't configure with generator.yml, you can copy the file out of the cache into your module dir and hack away. I prefer to take the "out of the box" admin generator as far as possible before customizing it, though.
i've been working with symfony for quite some time now and i've been using the admin generator for simply and complex situations. It's true that it saves time when developing CRUD modules, but i dont think that is not advisable for complex cases.
I think you should use it and also learn the power of customization the generator gives you. If you have complex Forms, leave that for form classes to manage and as you said, if your forms a quite more complex to render, well you should only take care of the rendering of that only segment of the view.
But, if you decide to make if without it, you should start thinking about creating all the view from scrap, that in my case takes quite time ( i'm not so versatile wiht css).
But this is only my opinion, hope this helps you make a more rational choice!
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 :)