I am using scaffolding in my application. However, I was wondering if I now really need to implement the CRUD Methods in my Controller class for example concerning production mode.
btw I am using grails 2.3.4
I appreciate your answer!
This is a rather odd question. You don't need to do much at all - make your app the way you want. If the generated CRUD pages help you, use them, otherwise don't. You can use them as starter code, removing actions and other code that you don't need and adding new code as needed. You can create code by hand or via scripts. Do what works for you :)
Related
I've been looking at Administrate source code and would like to know if it's a good practice or not the use of a generic controller and what implications it would have, like code complexity, performance degradation, etc.
Sometime ago, there was a gem inherited_resources that provide this feature, but since Rails 3.0 or 3.1 has been said we no longer need them.
So, since I have some very simple models (with only two or three fields) I could create a generic view and controller to manipulate them and save a lot of lines of "duplicated" code. Although I'm afraid, by avoiding repetition I could be creating another monster.
I've been looking for a Rails way to do this, but failed, so I would thanks some advice.
Note: I'm not looking to implement or use an admin dashboard, but use in my application instead
All Rails admin-panel implementations will make you hurt when you will try to make something more complex than stupid simple CRUD-application. I recomend you not to use such solutions. I had experiece in usage three different Rails's admin-panels and all of them had bad design and a lot of limitations. They are hard to mantain and extend their functionality.
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
I've been using Rails for a few months now, and I'm quite comfortable writing up a project & manipulating Rails to my needs, etc.
Recently I've been trying to get a little more advanced, so I've attempted to modify/add to the existing rails codebase: add new form helper methods, add a responds_to :pdf method, etc...and I've been having a lot of problems.
The difficulty is learning which code I need to modify; where that code is located, and how to ensure I don't miss related code in other files. I'm guessing there's a way people learn to do this, but at the moment I'm mostly just guessing-and-hoping.
I guess my question is, how do Rails folks go about learning where the code they need to modify is edited & the approach to editing it? It seems like it's just something you need to know from prior familiarity, but I'm guessing there has to be a simple method for understanding where (and what) to edit.
Any ideas appreciated...cheers
I highly recommend Jose Valim's Crafting Rails Applications
You go through advanced projects, building out the types of engines and customizations that will take you to the next level in your Rails development.
From the site:
This book will help you understand Rails 3’s inner workings, including
generators, template handlers, internationalization, routing, and
responders.
What you are asking for is how MVC works. Basicly you can say:
1.) Put logic to the model! The model is the pivot everything turns around.
2.) The Controller is a middleman between the model and the view. You dont put any logic here that isnt related to selecting data from the database that should be displayed in the view. If you use one selection logic more than once create a scope in the Model and use it in the Controller.
3.) The View is only there to display things! You dont put any logic here! All the logic comes from the model and the data comes from the controller. The only logic your using here are loops through arrays of data that should be displayed.
Then you have some things missing. If you have a task that is related to an external service like lets say a SOAP Service you write a class for that too! Just whithout using ActiveRecord::Base inheritance like its generated by the scaffolder. You can call this Class in other models. Dont put this to the controller or copy the code in every class that needs it! Stay DRY (Dont Repeat Yourself). Just write a class for it and include it in the other models!
Another thing thats a Database basic: Dont store data that could be calculated from other fields from the database! You can add methods that calculate the stuff you need but dont start with duplicates.
I've read about HMVC (Hierarchic Model View Controller) and it's flexible structure.
Have a look at this picture:
http://techportal.inviqa.com/wp-content/uploads/2010/02/MVC-HMVC.png
I wonder if the Rails 3 plugins are the answer to HMVC in Rails 3?
Based on the comments to Toby's answer it seems that you would like to be able to have MVC apps used as a component within a new app. Rails Engines (See http://rails-engines.org) provides this functionality. You simply install the engines gem and place apps in vendor/plugins and its modles/views/controller are all accessible.
This does not really conform to HMVC where the controllers in the new app delegate to other controllers. But like Toby I do not see the advantage of that.
What is nice about the Engines approach is that you can over ride any of models in the plugin by just adding a version of the model to the new apps app/model folder (same applies for views and controllers)
I have overidden app/views/layouts to give my Authentication app/plugin the same look and feel as the application it is included in.
For Rails 3 Railtie takes the place of engines and is officially supported (and actually used - Action Mailer is a Railtie plugin. I have not used it myself yet though.
Check it out at http://edgeapi.rubyonrails.org/classes/Rails/Railtie.html
A nice write up on it is also here http://www.igvita.com/2010/08/04/rails-3-internals-railtie-creating-plugins/
Rails has had plugins for a long time.
I doubt there is a technical reason why a controller couldn't dispatch to another controller, passing the request object along a chain. I just don't know what you gain by doing so - the diagram looks like spaghetti.
To me it's a misuse of MVC. I would suggest it is much simpler and more maintainable to push logic into lower-level models and classes and create a single controller that fronts the this logic, rather than creating a chain of controllers.
In the Rails 3 blog post, DHH mentioned the Cells project. I haven't used it but I am going to check it out.
The cart example shows well how that kind of functionality might clean up your application code. Code which retrieves data should be placed somewhere in controller. In every action or in a before filter. The Cell seems to be much better solution.
Please look at this rubyonrails-talk post: https://groups.google.com/forum/#!topic/rubyonrails-talk/0c4TT7UOGCw
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.