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!

Computers, Open-source, Personal, Ruby, Software, Thoughts, Web

Another Helping of Abstraction, Please

Rails 3.1 is soon to be released, and with it comes two new abstraction libraries – CoffeeScript, and S(ass)CSS. These libraries are used to generate Javascript code, and CSS definitions respectively. While abstraction libraries are nothing new to Rails, the inclusion of two more got me thinking about the direction that Rails stack is heading.

CoffeeScript’s syntax seems to be to make Javascript as Ruby-ish as possible. It describes Javascript’s curly braces and semicolons as embarrassing.

SCSS aims to address some of the repetitive elements of CSS through the use of variables, nesting, and mixins. This feels more acceptable to me than CoffeeScript, but my first encounter left me burned.

A few other abstraction libraries of relevance: Haml aims to generate HTML without the use of HTML tags. Additionally, Squeel‘s (MetaWhere 2.0) aim is to remove all SQL from your projects.

So what am I bitching about? Abstraction is a good thing right? I see two categories of abstraction. The first being the “good” kind, that allow you to be completely ignorant of the underpinnings. For example, Ruby converting down into machine code.

The “bad” kind of abstraction are the substitution of a language with a DSL. This creates a lot of issues starting with development and debugging. In the case of CoffeeScript and SASS, you have to compile the DSL files into Javascript, and CSS files. I feel like this compile step is a step back from what we gain working with dynamic languages like Ruby, and Javascript to begin with.

Development in these libraries also requires that you understand both the DSL of the library, as well as being familiar with the language of the generated code. This additional skill requirement adds time to a project, and raises the entry bar for new developers. Its difficult to be proficient at a language, and a DSL that generates that language at the same time. A Ruby developer told me yesterday that he was surprised at how rusty his knowledge of SQL had gotten. Its shocking to me that a web developer would struggle with SQL, but I think its an accurate sentiment on which many Rails developers would agree.

Another casualty of abstraction is performance. Not only is the generated code sub-optimized relative to coding it by hand, it is also being run through through more system calls to get there. You can either compile up front (CoffeeScript, SASS), or you can incur this penalty on-the-fly (Haml, Squeel).

While none of the libraries are a requirement of web development, when working on a team that uses these technologies you are expected to produce consistent code. Even though these libraries let you execute “native” code, doing so is discouraged because of the availability of the DSL. The syntax for embedding native code (if its even allowed) is often cumbersome, and loses editor functionality such as syntax highlighting and parsing.

Since when did Ruby on Rails web developers stop working with SQL, CSS, HTML, and Javascript? I am beginning to feel like the Ruby camp is becoming the far left extremists of the web development world. The web is built on these core technologies, and the benefits of abstracting them doesn’t seem to outweigh the costs.

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!

Apple, Computers, Linux, Open-source, Software, Thoughts, Web, Windows

The Rich-Internet-Application Bubble

It doesn’t seem to be a question of if, but when we will see the Rich-Internet Application (RIA) bubble burst. Adobe’s Flex platform, and Microsoft’s Silverlight platform promise the world, but their implementation seems to be flawed. The entire discussion seems to always remind me of the story of Java. Consider the following advantages and disadvantages of an RIA system over traditional HTML / Javascript / CSS:

Advantages:

  • RIA platforms promise “rapid application development” (so cliche in the development world). A developer can create a visually rich and interactive application inside the comfort and power of an IDE.
  • RIA platforms can consume data at a level that is not currently possible with current existing web technologies. SOAP, XML and other services can be consumed in a stateless web application.
  • Web applications are treated like traditional applications, offering added benefits like running offline

Disadvantages:

  • RIA platforms are specific to an IDE – in short controlled. Adobe’s Flex promises to be open source, but only on the client end. The “black box” will probably remain just that.
  • If open-source specifications are achieved (unlikely with Microsoft Silverlight) It will take years for alternate IDEs, and editors to support its functionality on a level comparible to what is currently offered
  • RIA platforms add another layer of complexity to an increasingly growing software stack with the need for web services to interact with database sources as the RIAs ironically are not able to.
  • HTML, Javascript and CSS are all free, standardized, open-source, cross platform, and ubiquitous. Microsoft’s Silverlight and Adobe’s Flex are both controlled and shaped by a single company.
  • RIA platforms require a browser plugin, since the technologies generate data that is not directly consumed by any current browser.

Hopefully we remember the failed promises of Sun’s Java VM. The marketing term “write once, deploy everywhere” has become something of an inside joke in the technology industry, as this is hardly ever the case. It should be more appropriately named “write once, deploy anywhere that supports platform ‘x’. This is made worse by the fact that as closed-spec platforms, the RIA browser plugin development is left to the companies pushing the platform. How well do you think Microsoft will support a Silverlight client on Linux, or iPhone?

Performance in RIA platforms has also historically been a sore subject. Java code runs by creating a host-specific virtual machine that abstracts all of an operating system’s details. This works against performance, as the virtual machine will always be the limiting factor – there is simply too much overhead involved.

What each of these companies are pitching to developers is the idea that HTML, Javascript, and CSS are old, and cumbersome to work with. Further, browser inconsistencies make truly agnostic client-side scripting, or styling very limited in implementation. Solutions like Prototype.js, or the CSS browser reset are needed to write agnostic code.

I just don’t buy into it.

First, HTML, Javascript, and CSS are made cumbersome by the fact that no browser (except possibly Safari) adhere to the standards agreed upon by the W3C consortium. Microsoft in particular is selling a tool to abstract browser development, while their browser consistently remains one of the least compliant available.

Second, I think that the success (undeniable when looking at their ubiquity) of HTML, Javascript, and CSS are due to the fact they are free, accessible, open-source, and standardized. Anyone who wants to be a web developer can start right now without ever spending a penny. Developers wishing to use RIA platforms must purchase a developer license to use the IDEs to generate the code.

I hope that the developers of the Internet don’t fall prey to the seduction of RIA offerings. RIA is simply a product being pushed soley on the basis of profit – not with the promise to make the web a better place tomorrow. Instead, I encourage everyone to ride out this wave, and let the technology’s bubble burst.