JoeStelmach.com

Ajax Busy Indicators Part 2

Tue, 06 Feb 2007 22:37:00 -0500

Just a follow-up to my last post on Ajax busy indicators, where I described how to implement a single image/callback to indicate the status of all the Ajax requests on your site. The limitation was that the image had to always be placed in a pre-defined spot on the page, which is less than desirable. This can be overcome by dynamically changing the position of your image based on which link/button was pressed. Consider the following javascript:


	function setBusyNextTo(link) {

	  linkPosition = Position.cumulativeOffset(link);

	  linkDimensions = Element.getDimensions(link);

	  imageHeight = Element.getDimensions('busy_img').height;

	  x = linkPosition[0] + linkDimensions.width;

	  y = linkPosition[1] + (linkDimensions.height / 2) - 

	    (imageHeight / 2);

	  $('busy_img').style.top = y + "px";

	  $('busy_img').style.left = x + "px";

	}

You can hook this up to your ajax links (or buttons) using the after callback:


	<%= link_to_remote("Action", 

			  {:url => {:action => "ajax_action"},

			  :after => "setBusyNextTo(this)"} )%>

This will place the activity indicator directly to the right of the link that was clicked. The code in my previous post will take care of actually displaying the indicator (via a generic callback.) Note that this code makes no assumptions as to the physical size of the indicator image - The image will be vertically centered next to the link. This makes it possible to try out a bunch of different indicators by simply changing the src attribute of your indicator's image tag. The vertical positioning will be taken care of, but the horizontal positioning may be a bit trickier. You will have to make sure that your link or button has enough empty space to the right of it to avoid placing your indicator on top of something.

This idea can be taken a step further by adding the positioning functionality to our links and buttons unobtrusively (say, in the body's onload handler.) This can be accomplished with the following beautiful piece of javascript:


	$$("a").each( function(anchor) {

		  anchor.onclick= function() {setBusyNextTo(this)};

	});

Be careful with this method though, as this will only affect those dom elements that were originally created at the last browser page load (as opposed to the last javascript dom manipulation.)

Ajax Busy Indicators

Thu, 25 Jan 2007 23:40:00 -0500

If someone told me back in 2002 that animated gifs would one day be popular again, I wouldn't have believed them. The image of a construction worker shoveling next to a road-block to indicate a site is 'Under Construction' still brings on a feeling of nausea. However, animated gifs are now proving to be useful and sometimes even necessary in modern day web apps. The difference is that now they have some usability characterstics instead of just looking cute. Since Ajax requests are made behind the scenes, the browser itself doesn't offer any form of visual feedback to indicate that a request has been made and a response is pending. Therefore, we're on our own with letting the user know something is happening and that the application isn't just sitting there being stupid.

So how do we do this? The easiest way is to place an image on the page and set it's display property to none. Then when an ajax request occurs, we simply show the image by setting it's display property to 'inline' or 'block', and hide it again once the request has finished. We can actually forget about the css completely by using the prototype Element methods instead.

Somewhere in your rhtml:


	<img src="images/spinner.gif" id="busy_indicator" 

	  alt="busy" style="display:none" />


	

	<%= link_to_remote("Click Me", :url => {:action => "action_name"}, 

	  :after => "Element.show('busy_indicator');",

	  :complete => "Element.hide('busy_indicator');")%>

I'm using the after callback in this example, which might generate some confusion. The after callback is invoked after the request has been made and the browser is awaiting a response. This differs from the before callback which is invoked before the request is even attempted. I guess the jury is still out on this one, but I feel that the after callback is more appropriate since it will display the image only if the request was actually made. If we use the before callback and the request fails for some reason, then the busy indicator will be sitting there spinning and the user will just sit there and wait. Using the after callback will not display the busy indicator in this situation, and the user will most likely click the link again since they see nothing is happening.

In this simple example, we might also have some style rules associated with the image to place it in a well defined position on the page:


	#busy_indicator {

		  position:absolute;

		  top:300px

		  left:100px;

	}

Now, what happens when I have lots of Ajax calls on my page and I'd like the busy indicator to be shown for each one? Using the solution above would require the very un-DRY-like repetition of the after and complete callback code for each link_to_remote, form_remote_tag, etc. Luckily, there's an easy solution to extracting this code into a common place.

The prototype library allows you to register generic callbacks that work across all Ajax requests (those invoked through prototype, ofcourse.) This makes it painless to show our busy indicator at the proper time. Add the following to your application.js file:


Ajax.Responders.register({

	  onCreate: function() {

		    if($('busy_indicator') && Ajax.activeRequestCount>0)

            Element.show('busy_indicator');

	  },

	  onComplete: function() {

		    if($('busy_indicator') && Ajax.activeRequestCount==0)

            Element.hide('busy_indicator');

	  }

});

Note that we are simply just moving our previously defined after and complete callback code. Those callbacks no longer need to be defined in the previous link_to_remote call (or any other Ajaxified link for that matter.) Also note that the before callback described previously is not possible at this level, since onCreate is invoked after the request is created, not before. This code will display our busy indicator as long as there is at least 1 outstanding Ajax request awaiting a response. This is accomplished by looking at the prototype's Ajax.activeRequestCount, which is updated each time an Ajax request is made through prototype (this is actually implemented in the prototype library by registering a callback, just like we're doing here!)

So this is a pretty good solution, but the thing I hate about it is the inability to move the busy indicator around on the page. Sometimes I'd like the indicator to display next to each link or button that I click. However, I don't want to have an image tag sitting next to every single link. That would suck. So what can we do here? One solution would be to still place only a single image tag on the page, but change it's position each time a link is clicked. We may even be able to take this one step further by walking down our dom and generically inserting an onclick handler to position the indicaotor next to each link/button that we press so we don't have to define the onclick handler ourselves each time a link is added. Also, I think it may be benificial to insert the image tag into the dom via Javascript, since the busy indicator is useless outside of an Ajax/Javascript context.

More On Object Graphs In Active Record

Sat, 30 Dec 2006 16:20:00 -0500

As I said in my last post, I can't help but to think there is a better way to persist object graphs in Rails applications. The solution I outlined last time seems to stray from the DRY principle (Don't Repeat Yourself,) and just seems to leave a bad taste in my mouth. Don't you wish there was some way to leverage the meta-programming capabilities of Ruby and Rails to solve this problem in a generic way? Me too. Consider the following sketch of a solution:


def update_object_graph(root_entity, entities_seen = [])

  # return if we've processed this entity already

  return if entities_seen.include?(root_entity)      

  entities_seen << root_entity

  errors = []


  parameter_name = root_entity.class.name.underscore

  # if paramaters are given for the root entity, then we update it

  if params[parameter_name]

    keys = params[parameter_name].keys

    index = keys.index(root_entity.id.to_s)

    root_entity.attributes = params[parameter_name].values[index]

    errors += root_entity.errors.full_messages unless root_entity.save

  end


    
  forward_associations = 

    root_entity.class.reflect_on_all_associations - 

    root_entity.class.reflect_on_all_associations(:belongs_to)



  forward_associations.each do |association|

    # ignore acts_as_versioned association tables

    next if(/::Version$/ =~ association.class_name)

    raise unless root_entity.respond_to?(association.name)


    # Deal with has_one associations

    if(association.macro == :has_one)

      assoc_entity = root_entity.send(association.name)

      new_errors = update_object_graph(assoc_entity, entities_seen)

      errors = errors + new_errors if new_errors


    # Deal with has_many and habtm associations

    else

      association_entities = root_entity.send(association.name)

      association_entities.each do |assoc_entity|

        new_errors = update_object_graph(assoc_entity, entities_seen) 

        errors = errors + new_errors if new_errors

      end

    end

  end 

  errors

end

The idea here is that we first update the current entity with any corresponding values in the parameters hash. Then we attempt to save the entity and collect any errors. Remember, since the save method is called on the actual instance of the entity in question, it's erorrs collection will be populated and used when rendering the page. Now things get interesting - we discover the associations of the entity, and then use reflection to obtain references to the actual objects that represent those associations. Now we recursively call persist_object_graph on each of these objects.

Makes perfect sense right? Let me first say that this code doesn't actually work: it is just a sketch of a solution and has lots of oversights (no support for composed_of aggregations, it makes assumptions about the names of things, etc.) However, I was hopeful that I could take this idea and run with it. Unfortunately, this solution hits a brick wall when we back up and take a real close look at the Active Record design pattern. Can anyone spot the subtle but major flaw here?

Persisting Object Graphs with Active Record

Fri, 29 Dec 2006 13:12:00 -0500

If given a choice between simple and complex, Rails will always lean towards the simple (actually, it crashes into the simple side of things.) Most of the time this is a nice, refreshing change from the J2EE world, whose committee seems to get off on adding complexity into every nook and cranny of the J2EE spec. However, sometimes there are real complexities in the problems we are trying to solve. Consider the following domain model:

Now, let's suppose you would like to display the rendered html version of this entire object graph to the user on a single page with only one form. If you've done any rails development in the past, you're probably thinking "It can't be that bad". After all, Rails almost enforces that you follow domain-driven design, so how hard can it be to satisfy this requirement? update_attributes to the rescue! Take a look at the RDoc:

Updates all the attributes from the passed-in Hash and saves the record. If the object is invalid, the saving will fail and false will be returned.

Sounds great right? But wait - what if the method fails? Can we still access the error messages as if i called the save or valid? method directly on each object? Will the framework know which properties have errors associated with them to insert the proper 'fieldWithError' class names while rendering the response? Unfortunately, the answer is No. The update_attributes method is therefore worthless to me, and exists as nothing more than an absolute tease. However, I'm sure the Rails core developers will argue that they were just 'keeping it simple'. I applaude that. But I still have to satisfy this requirement that goes against the seemingly conventional Rails wisdom of a single object per page.

So what options are we left with here? I could refactor my interface to break the object graph into multiple screens, but that would add lots of complexity to my user interface, which I believe should remain simple at all costs (even if it means adding complexity to the back-end.) So refactoring the interface is out. I suppose I could just walk the object graph and populate and save each object directly, collecting any error messages that arise as we make our way to the bottom of the graph. Populate and save you say? That's what update_attributes is for. So maybe we can validate each object on our way down, and then use the update_attributes on each object. Sounds good right? Wrong again. update_attributes maintains its own transaction, which means that once an object is updated, it cannot be rolled back if another object's validation or save fails. The entire group of saves needs to be wrapped in a transaction. It looks like the optimal solution in this case is to use the attributes= method to populate the attributes from the parameters hash and the save method to do the persisting, all within one transaction.

This solution will work (and does work for a couple apps I have written.) However, the complexity of the save operation increases for each entity you add to your domain model (luckily, this seems to be only a linear increase.) But seriously, I can't help but to think there's a better way to do this...

Javascript Trivia

Mon, 18 Dec 2006 22:23:00 -0500

I guess I should have learned this a long time ago - but when a tiny piece of code kicks my ass this bad, I like to share it with the world :) How many times do you expect the following Javascript to alert 'hi'?


function x() {

  for(i=0; i<8; i++) {

    y();	

  }	

}


function y() {

  for(i=0; i<2; i++) {

    alert('hi');

  }

}


x();

The answer - An infinite number of times! Believe it or not, when the Javascript interpreter comes across a variable without the var keyword in front of it, it automatically creates a global variable with the given variable name. Fun stuff.