Again I have a website where a lot of data transfer is done asynchronously and a large amount of the presentation is done using Javascript. Different users have different access to features across the site, and I can’t just rely on hiding links given the data is a simple HTTP request away. Protecting this data on the server side has always been easy to me, but I’ve typically found building the persistent abstractions I like to have far more difficult on the client side. As per usual, it’s probably just another issue I haven’t spent enough time to get a grip on.
It’s possible technologies such as Prism and Gears will help with this in the future. Unfortunately, it is the present.
This time I think I have a solution that I’m pretty happy with though. On the server side it involves using the existing HTTP response codes to indicate to the requester what happened with their request. On the client side the ajaxComplete() event is used to handle these codes.
jQuery will automatically call the function you specify as your callback in an AJAX request if the request is successful, so I’m only interested in handling failures. At the moment I’m assuming that all of my calls use JSON for their data format, but the alternative is a case I can handle later if need be. Only do what is necessary right now is a great credo I think.
So here is my event handler, it’s very simple but the documentation on the arguments to the event are a little slight. The success() call just makes a call to the function specified in the original call, hence passing in an empty array, simulating no records returned. The code I’m handling is for 401: Unauthorized, which in this case is the truth. This code will be sent back when I determine that the user is trying to access some data they aren’t supposed to. HTTP codes handle the majority of cases you’ll run into.
(function() {
if (typeof(jQuery) != 'undefined') {
jQuery().ajaxComplete(function(ev, req, settings) {
if (req.status == 401) {
settings.success([]);
alert('You have insufficient privileges.');
}
});
}
})();
The server side code is simple, it’s just a matter of sending back the appropriate header:
This function is specified in a global include where part of the website uses prototype, I’ve been slowly integrating jQuery. Therefore the first thing I do is check if jQuery has been defined, if it has then I register my function as the handler for the ajaxComplete event. Since it’s declared globally this will happen on every AJAX call. If the response code is 401 then first I pass back and empty array to my success handler so that the little loading notifier disappears, and then I notify the user of the error.
It seems to be a trend lately, but again this is just a very simple idea but I hope it saves someone some hassle. I know I’ve searched high and low on the topic and haven’t found a nice generic solution.
Animating table rows in the browser is problematic. You see, they aren’t block elements and as such don’t have a height or width property. Instead they take their constraints from the content inside them, and the elements that contain them. For rows this typically means they’re constrained by the containing table, and filled by the contained columns.
Today I wanted to slide a row up, and then when it had finished sliding I wanted to remove it from the DOM. Essentially giving it a nice effect when something is deleted.
Given that the height of a row is controlled by it’s content, I figured the easiest way to do this would be to wrap all of the content inside each column with a block element, in this case a div, and then resize those.
jQuery makes this extremely easy :
var el = $(options.element_prefix + id);
el.children("td").each(function() {
$(this).wrapInner("< div />").children("div").slideUp(function() {el.remove();})
});
NOTE : The div tag in the wrapInner() is malformed because it won’t display properly otherwise. Please remove the space between the opening bracket and ‘div’.
It’s all pretty easy to understand. Essentially my root element is a row, and so for each td in that row wrap it’s content in a div. Then for the child divs in each td, run the slideUp() method. The callback in the slideUp() method says after the animation is done, remove the row. Given the speed of computers these days, no one will notice that the last few columns quite likely just vanish instead of complete their animation.
I’ve written about Rails Rumble previously, the 48 hour event where teams turn an idea into a web application using Ruby on Rails. I was surprised to see the completeness of some of the applications that were developed this year as well as the utility of the ideas they implemented.
One of the more interesting articles I’ve seen in relation to Rails Rumble analysed the prevalence of various plug-ins and gems that teams utilised.
After a quick look there are a few points that specifically interest me :
jQuery is the most used Javascript library, even though it isn’t the default included with Rails. I think this says a lot about where jQuery fits in the client side coding space these days. Under further scrutiny it seems clear that jQuery had an even larger base of use than shown in that graph, as explained here.
1 in 3 teams used a skeleton application. All of those teams used Bort. That’s a pretty overwhelming statistic for two reasons. Firstly it means you should be looking at using skeleton applications if you aren’t already. Secondly anything that you develop that could be used in other applications should possibly be a gem or plug-in. Reuse doesn’t seem to be something you just talk about anymore.
Over 50% of people wrote tests as part of their application, and the majority of people used a Behaviour Driven Development framework such as Shoulda or rSpec (they got rSpec!). Keep in mind that even on a tight schedule most people using Rails are writing tests!
Over a third of applications offered OpenID support for authentication. Given I don’t even remember where I signed up for OpenID this surprises me. Maybe it’s time to join this bandwagon?
I think the article gives a good indicator where you should look to implement certain parts of your application. Generally speaking, if a lot of passionate developers are using a particular library or piece of code then you’d be wise to make the same choice.
I was writing some code today and I wanted to prompt the user to check if they wanted to delete a row of data only if there was some data they might not want deleted. Typically to do this I would loop through all the input fields and if any of them weren’t blank I would run the check. I figured that there must be a better way with callbacks or selectors, and after a little thinking I wrote this jQuery snippet :
row.find('input[value!=""]').length > 0
This basically says count the number of inputs with a non-blank value you find, inside the given row.
Just like my last post, it’s nothing amazing but it sure is a better way of doing things. If you look into the andSelf() method then you could also easily chain selects and other input types.
I’m also interested if someone has a better way to approach this problem?
I’m a big fan of Javascript frameworks that help me get things done, I’m a huge fan of anything that helps me get things done easier. My favourite framework though is jQuery after having tried a few just over a year ago I settled on jQuery as a better choice than Prototype and thankfully I’ve been proven right.
John Resig, the creator of jQuery is also a bit of a proponent for another framework called MochiKit. The idea of MochiKit is to “Make Javascript Suck Less” and as such doesn’t really offer many out there features that others might, it more concentrates on filling in functionality gaps that are present in the Javascript language.
These things include better comparator functions, which enable sorting and so on, also there are handy formatting functions, asynchronous functions and data functions for handling JSON. DOM manipulation looks to be very good, though whether it’s easier than jQuery is probably up to personal choice. Basically MochiKit seems to fill in the gaps of Javascript and do exactly what it says it does, make programming with Javascript suck less by giving you the functions you always wished you had.
I plan on checking this out and feel like it’s probably a worth addition to anybodys’ toolbox that is writing client side code.