Fast-track your Web apps with Ruby on Rails
To delete a particular record we will go for delete or destroy methods.But according to the names both looks very similar, but the functionality wise both are different. so lets check the difference between delete and destroy methods in Active Record.
Now first check what the delete method will do:
Delete method deletes the row with a primary key matching the id argument, using a SQL DELETE statement, and returns the number of rows deleted. Active Record objects are not instantiated, so the object‘s callbacks are not executed, including any :dependent association options or Observer methods.
You can delete multiple rows at once by passing an Array of ids.
It is much faster than the destroy method, skipping callbacks might bypass business logic in your application that makes the function to work fast.
example:
Delete a single row
user.delete(1)
Delete multiple rows
user.delete([2,3,4])
Destroy method:
The destroy method makes the SQL call to the database and destroys the row in the table that contains it. It does still allow you to manipulate the object in the application as long as it’s still in scope (i.e) the callbacks and
filters are allowed even after destroying the object.
example :
Destroy a single object
User.destroy(1)
Destroy multiple objects
users= [1,2,3]
User.destroy(users)
Category : Featured, Ruby on Rails
Mutable objects :
1)Mutable objects are objects whose state can change.
2)In Ruby, Mutability is a property of an instance.
3)Any instance can become immutable by calling the "freeze".
Immutable objects :
1)Immutable objects are objects whose state never changes after creation.
2)Immutable objects are thread-safe(A piece of code is called as thread-safe ,if it functions correctly during simultaneous execution by multiple threads).
Freezing Objects:
1:The freeze method in class Object prevents you from changing an object, effectively turning an object into a constant.
2:After we freeze an object, an attempt to modify the freezed object, results in TypeError.
3: freeze operates on an object reference, not on a variable.
4:This means that any operation resulting in a new object.
Example:
str = 'A simple string. '
str.freeze
begin
str << 'An attempt to modify.'
rescue => err
puts "#{err.class} #{err}"
end
# The output is – TypeError can't modify frozen string
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | def get_video_file_duration(inputFilename) command = "ffmpeg -i " + inputFilename.to_s + " 2>&1 | grep 'Duration' | cut -d ' ' -f 4 | sed s/,//" output = `#{command}` if output =~ /([\d][\d]):([\d][\d]):([\d][\d]).([\d]+)/ duration = (($1.to_i * 60 + $2.to_i) * 60 + $3.to_i) * 10 + $4.to_i end #return duration.to_s return "#{$2}:#{$3}" end |

Category : Ruby on Rails
Mod_rails has come to rescue people form tedious rails application development. With mod_rails the work has become a lot easier, you do not have to worry about different things just few steps and your application is up and running, ofcourse there are options to modify the deployment to your needs.
There are few prerequisites for mod_rails to work, first you need Apache and secondly you need Ruby and Rubygems.
Step 1: We need to update rubygems
sudo gem update
Step 2: We need to install mod_rails(passenger)
sudo gem install passenger
Step 3: Now we need to install Apache2 headers
sudo aptitude install apache2-prefork-dev
Step 4: Now we need to install Apache2 module
sudo passenger-install-apache2-module
There will be a screen which takes you further. If there are any dependencies that are needed then it will be asked for on this screen.
After successful installation there is just one thing left, we need to copy some lines to the Apache2 main config file , open the file “apache2.conf” in a text editor and then paste these lines at the end of the file:
LoadModule passenger_module /usr/lib/ruby/gems/1.8/gems/passenger-1.0.4/ext/apache2/mod_passenger.so
RailsSpawnServer /usr/lib/ruby/gems/1.8/gems/passenger-1.0.4/bin/passenger-spawn-server
RailsRuby /usr/bin/ruby1.8
Restart Apache
sudo service apache2 restart
Done!!
Here are the rails cheatsheet’s which will help you to get a good overview of how things work in RAILS.
Introduction
How many times have you walked away from some Internet forum because you could not remember your login ID or password, and just did not want to go through the tedium of registering again? Or gone back to re-register yourself only to forget you password the next day? Remembering all those login IDs and passwords is indeed an onerous task and one more registration for a new site seems like one too many. We have all tried to get around these problems by jotting down passwords on pieces of paper or sticking notes to our terminal – all potentially dangerous practices that defeat the very purpose of keeping a digital identity secure.
If you had the choice of a single user ID and password combination – essentially a single digital identity – imagine how easy it might become to sign up or sign in to new sites.
What is Openid?
OpenID is a single sign-on system, which allows internet users to log on to many different web sites using a single digital identity, eliminating the need for a different user name and password for each site. OpenID is a decentralized, free and open standard that lets users control the amount of personal information they provide.
Overview of the authentication process
When consuming OpenID what you are trying to do is ask the user for their OpenID (which is a URL) then ascertain from their OpenID server that they actually own this OpenID. Once you know that they own the OpenID you can then wack it in the session (and use it as a really lightweight means of identifying users between visits) or key it in with your own application specific account data if you need more power. This article is going to take you up to and including verifying the user’s OpenID. What you do with it is left to your imagination.
On a more granular level the verification process breaks down into these steps:
1. Get the user to give you their OpenID URL.
2. ‘Begin’ the verification process whereby your OpenID library of choice will work out the users OpenID server and, if successful, provide you with a redirect URL.
3. Redirect the user to the given redirect URL. You specify a return URL within this URL.
4. The user goes to their OpenID server, logs in and authorizes your site’s verification request and is then redirected back to your return URL.
5. Your server ‘completes’ the verification request and, if successful, confirms that this user owns this OpenID. The end.
So that’s essentially it. Some of the details of the transactions between your server, the user’s delegates and the OpenID are pretty complex but fortunately for us there are lots of good libraries for most platforms that mean you don’t need to bugger about with the crypotography and stuff. Woo hoo. For these examples we are going to use the ruby-openid gem but you can choose your own. Also note that East Media have a OpenID Consumer plugin for Rails that wraps even more detail with some generators but it’s good to understand the concepts before you let something write your code for you.
Get your library sorted
That’s easy. For us Rubyists its:
1 | $ sudo gem install ruby-openid |
Create your OpenID consuming controller
We are going to try to be as RESTy as possible here so we’ll create a singleton resource called openid. In routes.rb:
1 | map.resource :openid, :member => { :complete => get } |
Then we’ll set up a simple controller. Firstly, we’ll need to require the ruby-openid gem here. We are also going to need a method that gives us an OpenID consumer object which is the single most complex part of this whole thing (and it isn’t complex). First, here’s the skeleton:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 | require "openid"require 'uri' require 'openid/extensions/sreg' require 'openid/store/filesystem' class OpenidController < ApplicationControlle def index @title = 'Welcome' end def new # TODO: show a form requesting the user's OpenID end def begin # TODO: begin the OpenID verification process end def complete # TODO: omplete the OpenID verification process end def requested_url return "#{request.protocol + request.host_with_port + request.relative_url_root + request.path}" end protected def openid_consumer @openid_consumer ||= OpenID::Consumer.new(session, OpenID::Store::Filesystem.new("#{RAILS_ROOT}/tmp/openid")) end end |
The OpenID::Consumer constructor takes two arguments, the first one should be a hash like object that holds session data. That’s always going to be session for Rails. The second one takes a file store object which is used to store state information for the verification process. There’s lots (including an ActiveRecord store) but for many apps the filesystem store is fine.
Getting the user’s OpenID
The new action just needs to show a simple form posting the OpenID to the create action:
1 2 3 4 5 6 7 8 | <h1><%= @title %></h1> <div><strong><%= flash[:message] %></strong></div> <div><strong><%= flash[:error] %></strong></div> Please login with your OpenID Identity URL <div id="verify-form"> <%= start_form_tag :action => 'begin' %> Identity URL: <input name="openid_url" style="width: 200px" type="text" /> <input value="Verify" type="submit" /></div> |
Note that it’s convention to call the field openid_url so browsers will autocomplete nicely. They also recommend that you embed the OpenID logo in the form field. Get the logo then try some CSS like this:
1 | #openid_url {background: url(/images/login-bg.gif) no-repeat #FFF 5px;padding-left: 25px;} |
Beginning the verification
The create action is going to be responsible for kicking off the process:
1 2 3 4 | def begin openid_url = params[:openid_url]open_id_response = openid_consumer.begin(openid_url) redirect_to open_id_response.redirect_url((request.protocol + request.host_with_port + '/'), url_for(:action => 'complete')) end |
We simply get the OpenID and pass it to the begin method of our consumer object to get a response. We then handle the status of the response which can have a number of states. For this super simple example we are just going to look for success but in a production app you’ll need to handle error states more usefully.
If the response was successful we call redirect_url passing the trust root and the return URL. The return URL is simply our complete action. The trust root is normally the homepage URL of your site. We then redirect the user to the resulting URL where the user logs in to their OpenID server, authorises your verification request and is (normally) redirected to return URL you provided.
Completing the verification
When the user is redirected back to your application the server will append information about the response in the query string which the OpenID library will unpack:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 | def complete params_with_path = params.reject{ |key, value| request.path_parameters[key] } open_id_response = openid_consumer.complete(params_with_path, requested_url) case open_id_response.statuswhen OpenID::Consumer::FAILURE if open_id_esponse.identity_url flash[:message] = "Verification of #{open_id_response.identity_url} failed. " else flash[:message] = "Verification failed. " end flash[:message] += open_id_response.message.to_s when OpenID::Consumer::SUCCESS flash[:message] = "You have successfully verified #{open_id_response.identity_url} as your identity." if !params.blank? flash[:message] << "<hr /> With simple registration fields:" params.each {|k,v| flash[:message] << "<strong>#{k}</strong>: #{v}"} end when OpenID::Consumer::CANCEL flash[:message] = "Verification cancelled." else flash[:message] = "Unknown response status: #{open_id_response.status}" end redirect_to :action => 'index' end |
After passing the params hash containing all the info that the OpenID server sent us to the complete method we are given a response status to handle. Again for production apps more states should be handled but here, if the complete was successful we have completed the process. Here we just store the identity_url given in the session but at this point we could also do something like:
1 | session[:user] = User.find_by_openid_url(response.identity_url) |
Which would grab the users local account data based on the OpenID. Easy as pasty. However, there’s a few more bits and bobs you might want to know about.
Simple Registration Extension (SReg)
SReg is a basic means by which you can request additional information about the user from their OpenID server which you might normally use to prefill account details or other form fields. The information you can request access to is in the spec but there’s not much there at the moment. It’s still kind of useful. To request this information you need to add parameters to the redirect URL which is of course handled for you by your library. Revisiting the create action, we just add a call to add_extension_arg:
1 2 3 4 5 6 7 8 9 10 11 12 13 | def begin openid_url = params[:openid_url] response = openid_consumer.begin openid_url if response.status == OpenID::SUCCESS response.add_extension_arg('sreg','required','email') # <== here... response.add_extension_arg('sreg','optional','nickname,gender') # <== ...and here redirect_url = response.redirect_url(home_url, complete_openid_url) redirect_to redirect_url return end flash[:error] = "Couldn't find an OpenID for that URL" render :action => :new end |
Then in the complete action, extract the returned information:
1 2 3 4 5 6 7 8 9 10 11 12 | def complete response = openid_consumer.complete params if response.status == OpenID::SUCCES Ssession[:openid] = response.identity_url # the user is now logged in with OpenID! @registration_info = response.extension_response('sreg') # <= { 'name' => 'Dan Webb', etc... } redirect_to home_url return end flash[:error] = 'Could not log on with your OpenID' redirect_to new_openid_url end |
Immediate mode
Immediate mode allows you to attempt to verify the user without them leaving your site at all. This is normally possible if, during the first time you attempt to verify a user, they choose to always allow you to verify them and offers a slightly more streamlined login experience.
To implement this we first pass an extra argument to redirect_url:
1 2 3 4 5 6 7 8 9 10 11 12 13 | def begin openid_url = params[:openid_url] response = openid_consumer.begin openid_url if response.status == OpenID::SUCCESS redirect_url = response.redirect_url(home_url, complete_openid_url, true) # <== here redirect_to redirect_url return end flash[:error] = "Couldn't find an OpenID for that URL" render :action => :new end |
Then ensure that our complete action handles the OpenID::SETUP_NEEDED status by redirecting them to the OpenID server’s setup page:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | def complete response = openid_consumer.complete params case response.status when OpenID::SUCCESS session[:openid] = response.identity_url redirect_to home_url return when OpenID::SETUP_NEEDED redirect_to response.setup_url # <== here! return end flash[:error] = 'Could not log on with your OpenID' redirect_to new_openid_url end |
Fin
So that’s it.





