Use 'link_to_remote' unobtrusively

I have become a big believer in unobtrusive scripting utilizing lowpro, but I still like being able to use the Rails Prototype helpers because they are there and simple (not to mention hooked into plugins such as Redbox). But by default, the href on a link_to_remote is set to ’#’, which hardly gives the desired behavior when Javascript is disabled. However, with a quick rewrite of the link_to_remote helper, we can achieve unobtrusiveness (if not complete code separation) for any link_to_remote call:

def link_to_remote(name, options = {}, html_options = {})
    html_options.merge!({:href => url_for(options[:url])}) unless options[:url].blank?
    super(name, options, html_options)
end

Link_to_remote is actually just a wrapper on link_to_function, which accepts html options. However, if you set href in the html_options hash, it will override the default ’#’ and use the url specified. Now whether javascript is enabled or not, the same URL will be called. Respond_to to the rescue! Just drop some custom code into the action to which you are linking, and you can easily render out an HTML page or perform javascript behavior, depending on the format desired:

class SomeController < ApplicationController
  def some_action
    respond_to do |format|
      format.html { redirect_to :back } # reload the page we were just on
      format.js { render :update do |page| 
        # update the content dynamically
      end }
    end
  end
end

It’s a simple technique, but this has allowed me to use redboxes for modal controls and seamlessly degrade to a properly laid out form if javascript is disabled, all without changing a single line of code in the redbox plugin.

Share:

Comment on this post (1 comment)


Two from Intridea in Top Ten of October Rails Hackfest

Posted by on November 11th, 2007.

Josh Owens and Dave Naffis were the 7th and 8th leading contributors, respectively, in the October '07 Rails Hackfest. The Rails Hackfest recognizes developers who, by submitting patches, documentation, tests, and/or tickets, are actively involved in improving Ruby on Rails. Kudos to Josh and Dave for their accomplishment! Intridea is proud to give back to the Rails community, as well as other open source projects.


Share:

Comment on this post (0 comments)


Announcing 'OpenlySociable Micro' - an OpenSocial Widget Ruby Microframework

Posted by on November 9th, 2007.

What is it?:

‘OpenlySociable Micro’ is a clean, simple and concise way of writing OpenSocial widgets. It uses the Camping microframework and Mongrel to allow developers to write self-contained widgets for OpenSocial-enabled websites with none of the overhead of a full-blown Rails application.


Continue reading this post

Share:

Comment on this post (1 comment)


Announcing 'Cards' - A Facebook App

Posted by on November 8th, 2007.

Cards (beta) is a sweet little app that lets you send your already-uploaded Facebook photos or designs submitted by other users as greeting cards through Facebook.

Check it out at: http://apps.facebook.com/greetingcards


Continue reading this post

Share:

Comment on this post (0 comments)


OpenSocial, Buzz and the Tao of Releasing an API

Posted by on November 3rd, 2007.

Michael Arrington announced OpenSocial on TechCrunch two days before its official release. Prior to that, there were whispers everywhere about Google’s new social platform, but not many seemed to know what exactly was about to go down. Needless to say, this is good buzz. Two days before ‘launch’ the overwhelming mood among web developers, especially us who dwell in the realms of social networking, was one of intense (even feverish at some points) anticipation. What unfolded over the next few days, combined with what we observed of Facebook’s API venture, provides us a set of best practices that we can apply to an API release.


Continue reading this post

Share:

Comment on this post (0 comments)