Use case is pretty simple right now:

$(function(){
  $('#datetimepicker').dateTimePicker();
  $('#datepicker').dateTimePicker({showTime: false});
  $('#timepicker').dateTimePicker({showDate: false});
});

See the demo for more details. Enjoy!

First, some context. I’ve got this in my ApplicationController:

def require_user
  unless current_user
    store_location
    redirect_to login_path
    return false
  end
end

def store_location
  session[:return_to] = request.request_uri
end

def redirect_back_or_default(default)
  redirect_to(session[:return_to] || default)
  session[:return_to] = nil
end

… which allows me to do this in any of my controllers:

before_filter :require_user, :except => [:index, :show]

… and this is cool because now my users get redirected back to where they were going after they log in. I like saving my users a click or two here and there if at all possible.

There’s a problem with this though. What happens if somehow your user POSTs to an action that is behind require user? Well request.request_uri is *not* what you want to redirect to. Why? Because redirect_to is going GET the same url that your user was trying to POST to. And if you’re being a good Rails developer and using resources then you’re just going to smack them in a face with a big fat 404, and that’s not very nice.

I actually managed to do all of this over at github earlier today by trying to comment on a commit without being logged in. Want to see it in action? (until github fixes their ways) First, go to github and logout. Then find any commit and try to make a comment, you can figure the rest out. Go ahead, I’ll wait.

What is that critter anyways? It’s like a half octopus with a lizard tail and whiskers. wtf.

Anyways, here’s the simple fix:

def store_location
  session[:return_to] =
  if request.get?
    request.request_uri
  else
   request.referer
  end
end

If they’re GETing something let em keep on GETing it, otherwise take them back to where they were coming from.

This solution is only half-baked though. Any form data that the user has filled out will be gone and they’ll have to redo it. On the other hand you really shouldn’t be showing a form to an unauthenticated user that requires them to be logged in to hit it. If you really insist on doing that have fun saving all those parameters in the session or somethin in between requests. I’d imagine that’ll suck.