1
0
Fork 0
mirror of https://github.com/kbparagua/paloma synced 2023-03-27 23:21:17 -04:00
page-specific javascript for Rails done right
Find a file
Karl Bryan Paragua d9d50aeb8f Update README.md
2014-02-15 19:34:15 +08:00
app/views/paloma Simplify router.js 2014-02-15 15:04:27 +08:00
lib Basic spec and param fix 2014-02-15 17:32:32 +08:00
test_app Remove additional tests 2014-02-15 19:03:36 +08:00
vendor/assets/javascripts/paloma Record Paloma engine's last request 2014-02-15 15:35:54 +08:00
.gitignore Remove spec/tmp 2013-03-09 12:12:44 +08:00
Changelog.md Bug Fix: Converting Rails controller name to singular form 2013-10-31 16:07:55 +08:00
Gemfile Test commit with new git user 2012-12-21 14:29:09 +08:00
License Create License 2012-12-19 02:41:52 -08:00
paloma.gemspec Update version 2013-10-31 16:09:26 +08:00
README.md Update README.md 2014-02-15 19:34:15 +08:00
TODO.md Update old markdowns 2013-10-12 22:14:12 +08:00

Paloma

This README is for Paloma 4 only.

For version 3 README please go here.

For version 2 README please go here.

Paloma 4, why so sudden?

The last major version (v3) of Paloma introduced a major paradigm shift, and it took me a while to realize that some of the major changes introduced are not really that good and needed to be removed.

What's new?

(compared to version 2) It is now simpler and more flexible. The old callback thingy paradigm is replaced by a Controller layer for better abstraction. Generators are also removed, so programmers need not to follow specific directory structure, unlike in the old versions.

Previously, there are generators that create Paloma files, and these files are written in vanilla javascript. Because of that there are some users who are requesting for coffeescript setup. Now since there are no generated files programmers can write their code either by using vanilla javascript or coffeescript. Yay!

Controller

The new paradigm is patterned after Rails Controller, so it is easier to grasp than the old callback paradigm. Basically, you have a Paloma Controller counterpart for every Rails Controller.

How about Model and View?

It is tempting to convert Paloma 3 to a full-blown MVC or MVP (or whatever) framework. But I've decided to keep it simple and just provide a Controller component as way to execute a specific javascript code per Rails Controller action and give developers freedom on how to handle each action. So you can still have your own Model and View components and just use them in your Paloma Controllers, since a controller is just a middle-man.

Advantages

  • Choose what specific javascript code to run per page.
  • Easily make ruby variables available on your javascript files.

Quick Example

Paloma controller.

var UsersController = Paloma.controller('Users');

// Executes when Rails User#new is executed.
UsersController.prototype.new = function(){
   alert('Hello Sexy User!' );
};

The Rails controller app/controllers/users_controller.rb:

def UsersController < ApplicationController
    def new
      # a Paloma request will automatically be created.
      @user = User.new
    end
end

That's it! Simply Sexy!

Minimum Requirements

  • jQuery 1.7 or higher
  • Rails 3.1 or higher

Install

  • Without bundler: sudo gem install paloma.
  • With bundler, add this to your Gemfile: gem 'paloma'
  • Require paloma in your application.js: //= require paloma

Controllers

Controllers are just classes that handle requests made by Rails Controllers. Each Rails Controller's action will be mapped to a specific Paloma Controller's action.

Creating a Controller

A Controller constructor is created or accessed (if it already exists), using Paloma.controller() method.

var ArticlesController = Paloma.controller('Articles');

It will return the constructor function of your controller.

Note: Using Paloma.controller method, you can access the same controller constructor across different files.

Handling Actions

Every time a request to Paloma is made (A Rails Controller action is executed), an instance of a Paloma controller is created and the method responsible for the request will be invoked.

var ArticlesController = Paloma.controller('Articles');

ArticlesController.prototype.new = function(){
  // Handle new articles
};

ArticlesController.prototype.edit = function(){
  // Handle edit articles
};

Passing Parameters

You can also pass parameters to a Paloma Controller by calling js before render in your Rails controller. You can access the parameters on your Paloma Controller using this.params object.

Example:

users_controller.rb

def destroy
    user = User.find params[:id]
    user.destroy
    
    js :id => user.id
end

Paloma controller.

var UsersController = Paloma.controller('Users');

UsersController.prototype.destroy = function(){
  alert('User ' + this.params['id'] + ' is deleted.');
};

Advanced Usage

You can manipulate what controller/action should Paloma execute using the js method.

  1. Changing controller
class UsersController < ApplicationController
   def new
      @user = User.new
      js 'Accounts' # will use Accounts controller instead of Users controller
   end
end
  1. Changing action

You can use the symbol syntax:

def new
   @user = User.new
   js :register # will execute register method instead of new
end

Or the string syntax:

def new
   @user = User.new
   js '#register'
end
  1. Changing controller and action
def new
  @user = User.new
  js 'Accounts#register' # will execute Accounts#register instead of Users#new
end

Preventing Paloma Execution

If you want to Paloma not to execute in a specific Rails Controller action you need to pass false as the Paloma parameter.

def edit
  @user = User.find params[:id]
  js false
end

Gotchas

  • Paloma will not execute if the response is js, json, xml or any other format except html.

For example: render "something.js.erb"

Where to put code?

Again, Paloma is now flexible and doesn't force developers to follow specific directory structure. You have the freedom to create controllers and routes anywhere in your application.

Personally, I prefer having a javascript file for each controller.