Erik Jacobs A Real American Hero

The other day I wrote about needing to blank default values when text input fields gain focus in a form.  I had found a jQuery-based script that seemed to do the trick… or so I thought.

When RidingResource went beta, I was tailing the RoR logs and noticed that “ZIP” was getting sent as a value on form submission. After some further prodding, I realized that the jQuery form script I was using was not working in Internet Explorer. FireFox would have the default values not sent, but for some reason IE was not processing the jQuery in time and the default value in the text input was being sent along and wreaking havoc on the application.

I had to do some quick fixery to get it to work that way, but the search began for a better (read: functional) solution. Enter Jason Palmer and his jQuery Form Field Default Value plugin. Not to steal any of Jason’s thunder, but the plugin is elegant and doesn’t suffer any issues in Internet Explorer. You should give it a try.

So while this might seem intuitive, I found it a little tricky. Preliminary Google searching didn’t reveal anything inherently obvious. However, robbrit on Freenode was able to lend me a hand and I got it figured out.

As you might expect, restful_authentication’s before_filter, :login_required, will direct you to the sessions controller if you are not logged in. So, I initially applied this before_filter to the entire application by placing it as the first line in app/controllers/application_controller.rb

class ApplicationController < ActionController::Base
  before_filter :login_required

Unfortunately, this had unintended consequences. Because this requires login for *all* controllers and *all* actions, we find that we are caught in an endless loop. The login route sends us to /sessions/new, but since we are not logged in, this action tries to again send us to login. Oops!

Rails is kind enough to allow for some exceptions and other fun with filters. So, I initially realized that we should probably add an exception for the “new” action, since that is where we are redirected for a login. We add this exception by re-iterating the before_filter in the app/controllers/sessions_controller.rb:

class SessionsController < ApplicationController
  before_filter :login_required, :except => :new

Unfortunately, this did not quite cut it entirely. Do not forget that the new action essentially just renders the login form. The create action is where all of the *real* work is done. But, since we did not except create, we end up in a login loop. We can fill out the form, press the “login” button, but when we reach the create action we are not logged in. This causes the filter to fire off and send us back to… you guessed it… the new action.

Adding an additional exception (and destroy, just in case) provides the results we are looking for:

class SessionsController < ApplicationController
  before_filter :login_required, :except => [:new, :create, :destroy]

Hopefully all of this stuff will work for you, too. This is just one way I found to authenticate all controllers with restful_authentication as I had a particular application that we wanted to lock down. The extra fun with this type of stuff is that you could put a before_filter on the signup actions. This would have the effect of only allowing a user with an existing account to create new users. This is useful for development lockdown to a certain extent.

So, as some of you may know, I do a little Ruby on Rails coding on the side. The geek in me really is quite dominant, so I spend a lot of time in terminal with Vim pumping away at code.

Recently, in a project I’m working on with Ainsley, I’ve made use of Mislav’s will_paginate gem.  We had the folks over at Hustlewood design some truly awesome graphics, and then had the nice fellows at PSD2HTML cut up some HTML/CSS for us.

Well, needless to say, I then had to take that HTML/CSS and stitch it back into the RoR application that I was working on.  One of the issues I encountered was that Mislav’s plugin and the CSS that was provided were not playing nice together.

It took me a minute to figure out how to extend his gem, and I’m still not sure that I did it right.  I originally tried to extend the gem by putting some stuff into the lib area, but found that that didn’t work.  After poking around a bit, I found that re-defining the classes for will_paginate in environment.rb seemed to do the trick.  Here’s some of my modifications:

class WillPaginate::LinkRenderer
 
  def initialize
    @gap_marker = "<li>...</li>"
  end
 
  # Process it! This method returns the complete HTML string which contains
  # pagination links. Feel free to subclass LinkRenderer and change this
  # method as you see fit.
  def to_html
    links = @options[:page_links] ? windowed_links : []
    # previous/next buttons
    links.unshift page_link_or_span(@collection.previous_page, 'disabled prev_page', @options[:previous_label])
    links.push page_link_or_span(@collection.next_page, 'disabled next_page', @options[:next_label])
 
    html = "<ul>" + links.join(@options[:separator]) + "</ul>"
    @options[:container] ? @template.content_tag(:div, html, html_attributes) : html
  end
 
  protected
  def page_link(page, text, attributes = {})
    "<li>" + @template.link_to(text, url_for(page), attributes) + "</li>"
  end
 
  def page_span(page, text, attributes = {})
    "<li>" + @template.content_tag(:span, text, attributes) + "</li>"
  end
 
end

As you can see, I had to do a number of things.  Firstly, I had to re-define the gap_marker to be a list element.  By default, the gap marker is enclosed in a <span>, and that just wouldn’t work for me.  Secondly, I also had to re-define the page_link and page_span methods.  These methods are used as part of the output generation, but were simply generating <a> links. I had to make will_paginate output everything encapsulated in <li> elements, and I also had to force what would normally be spit out as a <span> to also be spit out as a <li> element.

I still need to do some tweaking here with the previous/next, but I think I may simply just modify the CSS at this point (it may be easier).

EDIT: This does *NOT* work in Internet Explorer. Please check here for more information! EDIT

I had a few fields in a form that I also wanted to play with. I know you’ve all seen those nice forms where you click into a text field that has some default values, and the values magically disappear. If you click away, and haven’t typed anything, the defaults magically re-appear. I originally found a few jQuery scripts that seemed to do the trick for one field, but I had two that needed modification, and I also wanted to not send the default values along with the form submission. Enter ToggleFormText, a jQuery plugin. This does exactly what I described.

It uses the “title” attribute of the <input> tag instead of the <value>. Through the magic of jQuery, any <input> with a definition for “title” has its value updated. Clicking in a field (giving it focus) causes the value to be erased. Clicking the submit button causes any fields with their value still equal to the title to be blanked out again. It’s quite delicious.

I really only had to do a couple of simple things:

In my application.rhtml layout:

javascript_include_tag "jquery-1.2.6.min", "jquery.toggleformat"

In my view, I simply modified my text field output:

text_field_tag "searchName", params[:searchName], :title => "NAME", :maxlength => 50
text_field_tag :zip, params[:zip], :title => "ZIP", :maxlength => 5

That was it! The wonderful plugin took care of the rest.

jQuery allows you to do some really powerful stuff with Javascript, so you should certainly check it out if you’re doing any kind of modern-era web design.

That’s all I’ve got for today. A departure from my normal tech bloggery, but at least it’s something interesting to someone out there.

So it’s been a little while since I’ve written a post, but that’s how this blog goes.  Sometimes I write lots of stuff, and sometimes I write nothing at all.

One of the things I wanted to do with the new blog is be a little bit “open source” about the projects I’m working on.  Not so much sharing all the code of the projects, but sharing little bits and pieces of interesting tidbits I find throughout my net travels.

One such bit and piece that I found recently is the seed-fu plugin.  This is a plugin for Ruby on Rails that allows you to, in a very YAML-like way, feed data into your application’s database with simple rake commands.  What’s the benefit of this?  Well, during development, it makes it extremely easy to wreck up your database and then re-populate it with some initial data.

While there are definitely other ways this could be done, seed-fu fit my needs at the moment, so I used it.  There are a bunch of other Ruby on Rails plugins that I use, but I’ll try to talk about them when I use them, and not go back through what I’ve used just for the sake of listing them.