Ajax Scaffold Generator for Rails

Posted by Eric Stewart Sat, 04 Mar 2006 20:22:00 GMT

Richard White has released the latest version of his Ajax Scaffold Generator for Rails. Since I have been heads down on a mostly non-Ajax application until recently I had missed this.

If you appreciate the value of scaffolding in helping you get going in a Rails project and you want to use ajax in your application, this is a very handy way start. It also is a nice way of just generating some code you can play with if you are new to Ajax and want to quickly be able to experiment. And it doesn’t look bad. What is generated looks nice, seems to work well, and might not be too far from production ready depending on your application.

I did perform an accidental experiment. I had previously generated scaffolding for a model/controller in my test project and and re-generated scaffolding using this new ajax generator. All worked well, but I ended up with tests that were testing the original non-ajax scaffold methods. The action methods are just about the same, but they now are designed to only be called via ajax calls. My original functional tests for the controller broke. Enter redirect_or_render.

With Courtenay’s helpful method, it’s pretty easy to get this tests passing again and have these controller actions now support ajax or non-ajax calls. For example, consider the ajax generator created scaffold method create on my sample controller for objects called Tasks:

  def create
    @task = Task.new(params[:task])
    if @task.save
      @headers['task-id'] = @task.id
      @headers['Content-Type'] = 'text/html; charset=utf-8'

      render :partial => 'task', :layout => false, :locals => { :hidden => true } 
    else
      render :partial => 'form_errors', :layout => false, :status => 500
    end
  end

This method expects to be called via xhr request and only needs to return a snippet of code. If we apply redirect_or_render the action becomes something like:

  def create
    @task = Task.new(params[:task])
    if @task.save
      @headers['task-id'] = @task.id
      @headers['Content-Type'] = 'text/html; charset=utf-8'

      redirect_or_render(
        { :action => 'list' },
        { :partial => 'task', :layout => false, :locals => { :hidden => true } }
      )
    else
      redirect_or_render( 
        { :action => 'new' }, 
        { :partial => 'form_errors', :layout => false, :status => 500 }
      )
    end
  end

Now the create action can be called directly as well via a normal request and still function as expected. Note that there is still a bit of work to be done in this case, since we’d really like to have the action render the new action template again so we can show validation errors on the Task. So for these cases, maybe a render_or_xhr_render method would be useful.

<!- technorati tags start ->

Technorati Tags: , , ,

<!- technorati tags end ->

Posted in , ,  | Tags , , , ,  | 1 comment

The New Web Platform and Leaving People Behind

Posted by Eric Stewart Sun, 23 Oct 2005 04:12:00 GMT

Thanks to AJAX, Javascript has had quite the revival recently. Web developers are suddenly re-engergized as their monotonous development strategies due to the limitations of browsers and their varied implementations are giving way to a new way of doing things.

I’ve been playing with these new techniques myself, trying to understand how it can and should be used and more importantly when it should be used.

Ajax isn’t really new. Well, the term is fairly new, and the techniques have been possible for a while, though obscure.

Javascript certainly isn’t new. But it’s capabilities across browsers are probably a little more standardized than they once were. We’re now seeing javascript libraries and components that were possible before, but nobody was really going there.

I read a thought provoking post on The Man In Blue that makes a good point regarding the web client as an application platform.

I think we are now at a crossroads. JavaScript is now developed enough to offer cross-browser, cross-platform solutions from the same codebase, and this has made it viable to develop large scale applications using it. Given that there is a difference between webpages and applications, and that they have different goals and requirements, it is meaningless to point out that a JavaScript application fails when you disable JavaScript. I could equally point out that Firefox fails when I remove my operating system.

Certainly there is a difference between what Google Maps or the latest Ajaxian RSS reader or email client are and the traditional informational web page. In the latter Javascript has typically been meant to add a little flash and enhanced usability yet was still relatively easy to degrade when Javascript was turned off in the browser. We’re in new territory now.

The New Web Application Platform

What has really changed? Well, the traditional web application is a server application. That’s where most of the code was executed, even to control what the user sees in their browser. Sure, some Javascript might be used in the same way as those old informational web pages: to enhance usability or give the user a little flash. But the server still knew what it had sent to the browser, and pretty much what the user was looking at.

The shift to the new type of web application is important. Now developers are trying to put as much of the work as possible in the hands of the browser. Rendering of the what the user sees as well as fetching data from whatever sources will be done more on the browser’s terms. For those familiar with good ol’ MVC software architecture we’re talking about just shifting where some of the view/controller logic lies and reducing the workload of the server while giving the user a more interactive experience.

Accessibility and Leaving People Behind

The Man in Blue posed the question:

“So, why can’t we require people to have JavaScript in order to run an application? You’re not targeting everyone, you’re targeting your market.”

We certainly can require Javascript for this application platform. It is being done! Just take your favorite new Javascript or Ajax web application that is impressing the masses and try it with Javascript disabled. It’s not going to work.

I’ll agree with The Man here that you must target your market. Where we might possibly disagree is that even with traditional web applications and even pages, people have restrictured their market unecessarily. That’s a whole other discussion on how to understand building a flashy, interactive site that can still be accessible.

You can certainly push this new Web Application Platform to its limits, using the latest Javascript and Ajax wizardry. But keep in mind that while accessibility APIs, toolkits, and techniques for native applications and traditional web pages have made great strides it providing greater accessibility you’ll be leaping ahead again and leaving them behind.

I’ll put it another way: when considering who your target market is, shouldn’t you have a damn good reason for leaving people out that want to user your application? When asking yourself how much and how soon about adopting these new techniques don’t just consider whether you can, but also whether you should.

Now I’ll try to quit being a hypocrite and try to go fix my own site’s accessiblity problems so more people can use it.

Posted in ,  | Tags , , ,  | 3 comments