As we all know, the “target” attribute is not valid in the XHTML Strict Doctype. That can be kind of a pain in the butt when you want to open a link in a new window.
If you’re using the Transitional Doctype you can do something like this:
<a href="http://www.wehaventthetime.com" target="_blank">WeHaventTheTime</a>
Now, with the code above, you just have to add the class “external-link” to any anchor tag in the HTML, and the JS will handle the rest.
<a href="http://www.wehaventthetime.com" class="external-link">WeHaventTheTime</a>
I guess I should probably take my own advice now, and apply the script to this blog… Do as I say, kids, not as I do.
Waaaay back in November of 2008, I contributed some code to the Open Flash Chart project. At the time, most charts in the library allowed for click events within the chart - one of the few that didn’t handle clicks was the bar chart. Unfortunately, that’s exactly what I needed for bar charts in an application I was working on for a consulting job with Assembla.
So for this top secret project I’m working on with @TopherBook, I’ve been looking into using background jobs to handle some long-running tasks that are non-essential to the user experience. I researched a few different options including BackgrounDRb, Background::Job and Delayed::Job. Eventually, I decided on using Delayed::Job because it’s simple, allows for multiple workers running on one machine, and requires little setup work.
A very well written tutorial by Adam Wiggins on using Delayed::Job to create a queue-backed feed reader was a great resource for helping me get started with Dj (Part 1, Part 2). However, there are two things that I don’t like about his implementation. First, it isn’t XHTML Strict valid - and as we all know I’m a bit OCD about valid code. And second, he is using a polling method to check whether the background job has completed.
For my project, using client-side polling isn’t going to cut it. I need to use some sort of server-side push method like Juggernaut.
So today, despite battling a nasty sinus infection-like cold, I decided to get started on setting up SA.org, a project I’m working on with @TopherBook. I’m not going to get into details right now - everything’s a bit hush-hush right now - but I felt I should mention SA.org to set some context for the subject of today’s post. Today, I want to discuss the “user system” in a Ruby on Rails application.
By “user system” I mean the part of your Rails app that manages user registration, login, logout, etc — the authentication part of the system. In the case of SA, my user system must also include authorization functionality for user roles — admin, member, moderator, etc.
When planning my user system for SA, I instinctively thought of techoweenie’s restful_authentication plugin. It’s basically the standard in authentication plugins and it’s one that I’m very familiar with. However, after reviewing the Authlogic plugin, I’m thinking of changing things up a bit for SA. Authlogic looks really easy to customize and to fit to my needs. I like how easy it (looks like it) is to use and that I can use only email addresses instead of usernames for login. I also like that the session management allows for a “remember me” type functionality as well the ability for a session timeout after a certain period of user inactivity. It also allows for a certain level of stateful authorization (active, approved, confirmed). Basically, it covers what I need, so why not give it a shot?
But there was still the question of which authorization plugin to use.