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.
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 have developed few apps in Rails, and I needed to develop an API. I received the advise to build it in Sinatra, so I started looking into it.
It seemed quite nice, but it seems that a lot of things you get automated in Rails does not seem to exist in Sinatra. Specifically, I seem to have to write my resources from scratch. eg. The model itself, the migrations, and the REST routes.
I was wondering if there are any generators for Sinatra like the ones provided by Rails? Or should I simply use Rails if I want these kind of things automated?
Check out the sinatra-rest gem that can be used to handle RESTful routes. Quoted below for convenience:
[sinatra-rest is] a set of templates to introduce RESTful routes into Sinatra. The only thing for you to do is to provide the views. Automatically works nicely for models based on ActiveRecord, DataMapper, or Stone.
For example, if your model’s class is called Person you only need to add this line:
rest Person
Which will add the following RESTful routes to your application. (Note the pluralization of Person to the /people/* routes.)
Verb Route Controller View
GET /people index /people/index.haml
GET /people/new new /people/new.haml
POST /people create → redirect to show
GET /people/1 show /people/show.haml
GET /people/1/edit edit /people/edit.haml
PUT /people/1 update → redirect to show
DELETE /people/1 destroy → redirect to index
I don't personally use Sinatra but a lot of feedback I've gotten from other Rails developers is that they eventually end up switching back to Rails. I'm sure there are good arguments for using Sinatra over Rails, but if you already know Rails, and you don't have speed or application size constraints, I would just stick with that.
Another alternative to Sinatra is the Rails API project which doesn't include any of the view-related part of the Rails framework. I have used that in the past and liked it, but was it better than just using Rails? It's hard to say.
You should check out Padrino if you must have Sinatra.
Padrino is a ruby framework built upon the Sinatra web library.
Sinatra is a DSL for creating simple web applications in Ruby. Padrino
was created to make it fun and easy to code more advanced web
applications while still adhering to the spirit that makes Sinatra
great!
Or as Beerlington mentioned, you could use Rails API if you feel more at home with Rails. We've been using it recently with good success. We created a Simple API, with a mongo backend. Starts up very quickly :)
Or should I simply use Rails if I want these kind of things automated?
If you're that used to Rails that using Ruby is a problem, then maybe. Alternatively, you could try this API generator that uses Sinatra:
https://github.com/mattetti/Weasel-Diesel
Hey guys and merry christmas!
I'm new to ruby on rails and I'm still a little bit confused about some stuff:
When do I need to create a new controller and when not?
I want to create an app with a single searchbox and search through all of the articles. Should I create an Controller for the startpage (the searchbox) and for the search? Should I create controllers for the static pages?
Should I use an Admin interface gem or create my own?
The normal user should now have access to creating articles, just the admin. Should I use one of the admin interface gems or create my own?
Ruby on Rails follows the MVC framework, controllers are classes that contain your actions, so you need to add an action for every function your website will provide.
Technically you could have all actions in one controller but that would be just terrible, so we usually create different controllers to organize your routes and code in a better way.
Follow the Rails guide on controllers.
For the admin interface gem, you could use devise and cancan, they are both very reliable and well tested.
Ruby on Rails is indeed MVC, which means that controllers connect Models to Views. So in general it is good practice to think more resource-oriented: per resource you want found/presented, you create a controller. In your case something like:
ArticlesController : your main view, with the searchbox
PagesController : for static pages, if you need some erb/haml
admin/ArticlesController: for administration of the articles
Now, completely static pages can just as well be placed under the public folder, no need for a controller unless you need some dynamic info to be on the pages (e.g. a total count of articles).
With regards to your search-box: imho this is just a parameter for your index page. E.g. on the index you show the ten most recent articles, and when searching on some term, you show the relevant articles, but on the same controller and the same action.
With regards to the admin interface: yes, use gems like rails_admin or active_admin and it will get you started in no time at all. So definitely do that. But those gems are, of course, very general and might not suit your needs completely. It that should be the case, you can always easily revert later.
HTH.
Merry christmas!
As Khaled suggested Rails being MVC architecture it is always good to have controllers of each page. Even though you might have a static pages for now, but latter when you are trying to make the site dynamic one, then you will be in whole lot confusion of where to add a method for a particular view page.
Generally it is better to use a gem instead of making it from scratch.
You can look into this link which teaches you how to use devise and cancan with twitter bootstrap(for views). But if you are planning to learn rails then I better recommend you to do it from scratch as you will have an idea of what is happening. You can see this tutorial which does most of the task through scratch.
Enjoy Rails!!
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.
In Symfony i just have to create models with ORM Designer and export it to symfony as a schema.yml and then use a symfony command to create tables, models and forms.
I wonder if there is an equivalent to the RoR so that you dont have to create models manually by hand?
It saves a lot of time using GUI for this kind of tasks and it is less error-prone.
thanks
it should be possible to support RoR in ORM Designer. The trouble is that we know only PHP and wouldn't be able to beta test RoR support and create unit tests. But if there is anybody willing to help, please let us know at support at orm-designer dot com and RoR support can be released within a few months.
You can use the model generator with script/generate model to create a model class and migration. A great reference on migrations is cheat migrations which is available via the cheat command.
You could use the scaffold generator as per Getting Started with Rails, however scaffolds are "considered harmful" by many (including myself). I prefer to generate an initial migration with script/generate migration, tweak it to suit and then create/update my model, routes, controllers and views manually.
If you are still starting out, you will probably find it helpful to run through Getting Started with Rails at least once.