Computers, Open-source, Web

Configurable Javascript In Place Editor

Why do we need another in place edit library for Javascript? This one is different of course! This library allows for a high degree of customization due to its modular nature. Each action on an in place edit object (submitting on blur, adding a class on focus, toggling a label on click, etc) is complete isolated and designed to stack with each other. This allows for one library to accomplish a wide variety of in place edit functionality in the same project. You can even have different functionality on the same page if you wish.

Setup is a breeze. Just grab the latest copy of the Javascript library from https://github.com/bsimpson/in_place_edit. You will need to be using jQuery in your project, since this plugin depends on it to work. Once you have include both jQuery, and in_place_edit.js, you can initialize it like this:

  $(function() {
    $('.in_place_edit').inPlaceEdit();
  });

The argument passed is the CSS selector that contains the form on which you wish to use in place edit.

Next, we need to configure the form to tell it what actions we want it to perform. If we want basic edit in place functionality, we can add “submit_on_blur” to have the form submit when a blur event is received. Note that this only occurs if the contents of the form have changed, in order to save on the number of server posts.

<div class="in_place_edit" data-in_place_data="submit_on_blur">
  <form action="#" method="post">
    <input type="text" name="foo" value="foo" />
  </form>
</div>

The options are simple, and the combination are many. Check out the following options to see what you can do with your form fields on the DEMO page.

Happy in place editing!

Update: This plugin has been updated to be a jQuery plugin. Thanks to jsumners for providing lots of help!

Ruby, Software, Web

Serve JSON Remotely with Rails and JSONP

Have you ever found yourself needing to query data from another domain in Javascript? Because data in Javascript is usually fetched via AJAX, you will find yourself inside the Javascript sandbox of the Same Origin Policy (SOP). This leads you to immediately finding a way to circumvent this security via something like a proxy server. Fortunately for us, it is well known that the script tag’s “src” attribute is not limited to this restriction. Using this behavior, we can easily query data from across domains without the use of a proxy. The concept that I will be showing below is JSONP proposed by Bob Ippolito

To start with, lets take a look at how JSONP works. As a great example, go to this URL and look at the very beginning of the JSON response. It leads right into the JSON. Now, lets go to the same URL, with a callback variable in the query string. Try this link. Now you can see that the JSON result is wrapped inside of “test(…)”. This is padding the JSON result, hence the name. Because this is wrapped inside a function call, when the data is returned to our requesting resource, it will be passed to a local function with the same name – in this case “test”. So, we can write something like this:

function test(data) {
  console.log(data);
}

This would echo the result of the request out to our Javascript console.

To see a fully working example, lets include our Javascript library on the requesting end. If you are using JQuery, this functionality is built in, using the “callback=?” functionality, and an inline method. Congratulations – you are one of the cool people and you are done for a second. If you are using Prototype.js, you will need to extend its functionality with a community contributed patch, such as this one. Just include this in a separate file, or merge and minify, etc. Whatever makes you happy.

Lets talk about the server for a minute. If you are running Rails, lets setup a sample controller method that we can access. For example, I have the following:

# app/controllers/users_controller.rb
def show
  respond_to do |format|
    format.json do 
      render :inline => "#{params[:callback]('testing JSONP')" 
    end
  end
end

You can see that this action, show will respond to a Javascript request, and pad the result with the name of our callback variable. More on this in a second.

Now, lets fire up the server, and test out or new code. On the requesting end, do the following:

getJSON('http://path/to/server/users/show?callback=?',
  function(data) {
    console.log(data);
  }
);

We have taken the Javascript function from earlier, and made it inline, with our getJSON call. Change your URL path to reflect your Rails server. You should get a response like below if you go to the Rails server directly in your browser:

container('testing JSONP')

Now, within your requesting page, when you reload you should see the response ‘testing JSONP’ in your console log. Congratulations, you have just served JSON cross-domain without going to jail for breaking the SOP law.

It turns out that Rails handles this beautifully. Per the documentation for render:

Sometimes the result isn’t handled directly by a script (such as when the request comes from a SCRIPT tag), so the :callback option is provided for these cases.    
# Renders ‘show({“name”: “David”})’    
render :json => {:name => “David”}.to_json, :callback => ‘show’

We can refactor our controller to look like this instead:

# app/controllers/users_controller.rb
def show
  respond_to do |format|
    format.json do 
      render :inline => 'testing JSONP', :callback => params[:callback]
    end
  end
end

Rail’s render will pad the JSON response if a callback variable is present, or just serve the JSON response otherwise. Happy cross-site scripting!