Flowdock
alias_method(p1, p2) private

Makes new_name a new copy of the method old_name. This can be used to retain access to methods that are overridden.

module Mod
  alias_method :orig_exit, :exit
  def exit(code=0)
    puts "Exiting with code #{code}"
    orig_exit(code)
  end
end
include Mod
exit(99)

produces:

Exiting with code 99
Show source
Register or log in to add new notes.
August 18, 2016
0 thanks

Volt Framework for Ruby

Volt – a new Framework for Ruby where both the server and client sides are written in Ruby via OPAL (a ruby to JavaScript compiler) so developer can write dynamic applications without writing a single JavaScript code. Volt is similar to Meteor but it doesn’t have all the portions of Meteor.

The Basic Setup for Volt Framework

Let us install Volt and create an empty app. Make sure that you have ruby (>2.1.0) and ruby gems installed.

Install Volt Gem :

gem install volt

We can create a new project using the volt gem:

volt new sample_project

Fire up the web server:

bundle exec volt server

We can access the Volt console with:

bundle exec volt console

The Opal Compiler

Volt applications run Ruby on both frontend and backend. So the puts statement in a controller action appears in browser window and not in terminal console. And also writing Ruby code for the front end with Volt is very easy. The opal compiler translates Ruby to JavaScript. Amazing thing about it is that there is no compilation process to follow and no build tools to install. When you run volt server, everything takes place in the background. No refresh or restart is needed when you do changes to code and data.

Calling a JavaScript alert with Ruby

# Calling JavaScript functions in Ruby
module Main
class MainController < Volt::ModelController
# Called from front end when “todos” route loads.
def todos
alerttotes amaze’
end
end
end

Easy Syncing via Reactive Models

Concentrate more on this part when learning volt. Volt::Model acts as hash-like Ruby objects that sync between the front end and back end simultaneously. Usually, updates to the model happens automatically. The concept of “stores” in Volt is used to sync application data in persistent and non-persistent forms. And also a uniform means of syncing data between local storage, MangoDB, cookies, sessions and URL params.

Let’s check how to create real-time chat app of Ruby and HTML:

# Create a persistent data model. This gets stored in MongoDB.
class ChatMessage < Volt::Model
end

View Code:

<:Body>
<form e-submit=”say”>
<input class=”form-control”
type=”text”
value=”{{ page._input }}” />
</form>
<ul>
{{ _chat_messages.each do |msg| }}
<ul>
<button e-click=”msg.destroy”>X</button>
{{ msg._text }}
</ul>
{{ end }}
</ul>

Full HTTP Endpoint Support

Volt is not only for real-time framework. It also provides workflows for traditional HTTP application development. Checkout an example from GitHub :

# Routes for HTTP endpoint
get/simple_http’,
controller:simple_http’, action:index’

get/simple_http/store’,
controller:simple_http’, action:show’

post/simple_http/upload’,
controller:simple_http’, action:upload’

# Example controller

class SimpleHttpController < Volt::HttpController
def index
render text:this is just some text’
end

def show
render text:You had me at “\
“#{store._simple_http_tests.first._name}”
end

def upload
uploaded = params[:file][:tempfile]
File.open(‘tmp/uploaded_file’,wb’) do |f|
f.write(uploaded.read)
end
render text:Thanks for uploading’
end
end
May 1, 2015
5 thanks

Very bad documentation

This is terrible documentation. It makes it very hard to understand what the arguments mean.

The signature is

alias_method(p1, p2)

So what do p1 and p2 mean? The description doesn’t refer to them at all, but to new_name and old_name. How are we supposed to know which is which?

And then it gets even worse in the code sample:

alias_method :orig_exit, :exit

From the naming it sounds like the first argument is the original method name.

Documentation is supposed to resolve this kind of confusion, not create it.

April 8, 2010
2 thanks

Bad example

Note that it would be better to avoid the alias_method line in the example and just call super.

March 3, 2011
1 thank

Perfectly applicable

@rkh You would be correct if this code had occurred in a subclass who’s parent method was being overridden.

However, defining the method in this manner is completely removing the old method - as if you had written code like this:

class MyClass
  def do_something
    puts "We're doing some stuff here"
  end

  def do_something
    puts "The old do_something method no longer exists!"
  end
end

MyClass.new.do_something
# => "The old do_something method no longer exists!"

Of course this is non-sensical. But the idea is that you have either included a module, or monkey-patched an already existent class, and completely replaced the old method. super(*args) will not work

October 10, 2012 - (>= v1_9_1_378)
1 thank

Bad Example

@nZifnab it is a bad example because an included module is basically a class.

module Mod
    def exit(code = 0)
        puts "Exiting with code #{code}"
        super
    end
end

include Mod

exit 99

produces

Exiting with code 99
December 10, 2012
1 thank

@drewyoung1

Including module in a class does not automatically over-write methods defined with the same name.

Ex:

module Mod

def exit(code = 0)
  puts "Exiting with code #{code}"
  super
end

end

class OriginalClass

include Mod
def exit
  puts "Original message"
end

end

OriginalClass.new.exit 99

Produces:

exit': wrong number of arguments (1 for 0) (ArgumentError)

if you use this construct, the alias_method will work similar to super:

module Mod

alias_method :super_exit, :exit
def self.included base
  base.instance_eval do
    def exit(code = 0)
      puts "Exiting with code #{code}"
      super_exit
    end
  end
end

end