It doesn't matter how beautiful your theory is, it doesn't matter how smart you are. If it doesn't agree with experiment, it's wrong.
The actual town of 'Jersey Shore' is located in Pennsylvania - not in New Jersey
- Blog Categories
- Software (29)
- Music (11)
- Life (4)
- Cars (3)
- Randomness (4)
-
Ajax Busy Indicators Part 2
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
aftercallback:<%= 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
srcattribute 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
onloadhandler.) 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.)
Tuesday, February 06, 2007 10:37 PM EST0 Comments Filed in: Software -
Ajax Busy Indicators
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
aftercallback in this example, which might generate some confusion. Theaftercallback is invoked after the request has been made and the browser is awaiting a response. This differs from thebeforecallback which is invoked before the request is even attempted. I guess the jury is still out on this one, but I feel that theaftercallback is more appropriate since it will display the image only if the request was actually made. If we use thebeforecallback 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 theaftercallback 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
afterandcompletecallback code for eachlink_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
afterandcompletecallback 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 thebeforecallback described previously is not possible at this level, sinceonCreateis 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'sAjax.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.
Thursday, January 25, 2007 11:40 PM EST17 Comments Filed in: Software -
More On Object Graphs In Active Record
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
savemethod 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 callpersist_object_graphon 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?
Saturday, December 30, 2006 04:20 PM EST0 Comments Filed in: Software -
Persisting Object Graphs with Active Record
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_attributesto 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
saveorvalid?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. Theupdate_attributesmethod 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_attributesis 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_attributesmaintains 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 theattributes=method to populate the attributes from the parameters hash and thesavemethod 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...
Friday, December 29, 2006 01:12 PM EST0 Comments Filed in: Software -
Javascript Trivia
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.
Monday, December 18, 2006 10:23 PM EST0 Comments Filed in: Software