Customising form controls in Rails

Russell Quinn — Sat, 02 Feb 2008 22:23:55 +0000

Here is a simple way to implement custom form controls while still using Rails’ standard helpers. For this example, we’ll implement a two-state graphical alternative to a check-box (usually implemented by the operating system and uncustomisable via CSS), which represents a standard boolean field in your database model.

Normally we’d do something like in our view:

    <%= form_for @model, :url => { :action => :create } do |f| %>
        <%= f.check_box :someBool %>
        <%= f.submit("OK") %>
    <% end %>

But we’d like to use something a little like this to represent our field instead:

Firstly the images are added to our Rails view via the helpers, with the addition of assigning each one an ID and an inline style to hide the one opposing the required default state:

    <%= image_tag("signUpItemActive.gif", :size => "13x18",
        :alt => "Active", :id => "checkActive") %>
    <%= image_tag("signUpItemInActive.gif", :size => "13x18",
        :alt => "Inactive", :id => "checkInactive",
        :style => "display:none;") %>

These are then both wrapped in a single anchor tag, which is given an onclick handler to a JavaScript function.

    
         <%= image_tag("signUpItemActive.gif", :size => "13x18",
            :alt => "Active", :id => "checkActive") %>
         <%= image_tag("signUpItemInActive.gif", :size => "13x18",
            :alt => "Inactive", :id => "checkInactive",
            :style => "display:none;") %>

The next step is to modify our standard Rails form to assign the check-box an ID, and hide it with some more inline CSS styling. This means it won’t be visible, but will continue to send its value when the form is submitted:

    <%= f.check_box :someBool, :id => "hiddenCheckBox", :style => "display:none;" %>

The JavaScript function can then be defined in Application.js (this could of course be modified to take the IDs as parameters):

    function toggleCheckBox()
    {
        elementActive = document.getElementById('checkActive');
        elementInactive = document.getElementById('checkInactive');
        elementHidden = document.getElementById('hiddenCheckBox');
 
        if (elementActive && elementInactive && elementHidden)
        {
            var state = (elementActive.style.display == "none");
            elementHidden.checked = state;
            elementActive.style.display = state ? "inline" : "none";
            elementInactive.style.display = state ? "inline" : "none";
        }
    }

There we go! Clicking the dummy check-box graphic will toggle the images and set the value in the hidden check-box at the same time. There is only one remaining step and that is to set the default state of the images to match the existing value of the boolean field. Without this the graphics and the form are likely to get out of sync. Even if the form is for creating a new record, the page will be shown again in the event of a validation error.

Another JavaScript function can take care of this:

  function setCheckBox()
    {
        elementActive = document.getElementById('checkActive');
        elementInactive = document.getElementById('checkInactive');
        elementHidden = document.getElementById('hiddenCheckBox');
 
        if (elementActive && elementInactive && elementHidden)
        {
            var state = elementHidden.checked;
            elementActive.style.display = state ? "inline" : "none";
            elementInactive.style.display = state ? "inline" : "none";
        }
    }

Then call this from the page’s body onLoad event:

    <body onload="setCheckBox();">

Multiple Rails applications

Russell Quinn — Wed, 30 Jan 2008 00:37:02 +0000

We are midway through a large project at the moment. It’s our biggest Ruby on Rails project for a client to date and consists of a front end and an administration area based on our DATA CARTON technology. Early on we faced several organisational conflicts between these two opposing forces.

Our DATA CARTON framework was adverse to settling in directly with its public facing companion, our models (while obviously the same) were actually required to be configured in subtly different ways, and with multiple developers and designers working together, we decided to split them into two applications both pointing at the same database.

While these logical units promised simpler security, cleaner directory structures and more streamlined development, we hadn’t tried this before but decided to just forge ahead anyway. These are the problems we encountered and how we solved them:

1. Logins

Our front end is community-based and all users of the system from newsletter subscribers to administrators share a users table. The first thing we did after pointing our database.yml file at the same database was to try logging in to both applications with the test user we had created. After only a 50% success rate, we traced the problem to our password encryption method that uses a mixture of the user’s password choice, a salt and an application specific key string. Different keys are going to result in different hashes and incompatible authentication routines in the applications. A quick switch to using identical strings and we were successfully creating users and logging-in in all possible combinations.

    def self.encrypt(pass, salt)
        finalString = pass + 'somekey' + salt
        Digest::SHA1.hexdigest(finalString)
    end

2. Sessions

Our next thought was ’sharing sessions would be nice’. Linking administrators directly to the backend from their frontend toolbar without having to login again, passing secret messages back and forth, that sort of thing. Rails offers cookie-only sessions or database based ones. Using the more data-sensitive one is a simple matter of uncommenting these lines from the application’s environment.rb:

    config.action_controller.session_store = :active_record_store

Then in the same file (environment.rb) you’ll find your session security key and secret:

    config.action_controller.session = {
        :session_key => 'some_secret_key',
        :secret      => 'some_secret_hash'
    }

Rails generates both of these automatically when creating your application. They are sent with every non-GET request (i.e. PUT, POST, DELETE) to verify your session and protect against cross-site forgery (there’s actually a few fiddly issues with getting in-place edits working while using this method, but I’ll save that for another post).

The important thing here is to again make sure all keys and secrets are consistent across both applications. So pick one and copy it across. Once you’ve synchronised your environment.rb session settings, you’ll need to uncomment and duplicate your session secret from the top of controllers\application.rb too. Now you’re sharing sessions!

	protect_from_forgery :secret => 'some_secret_hash'

3. Subdomains

We quickly realised that our session sharing was not going to be as smooth as first anticipated, as we typically run our client’s backends on an admin subdomain (i.e. http://admin.abcdefg.com) and as cookies don’t take kindly to being requested by subdomains that haven’t sent them, we still didn’t have our single login functionality.

After much brainstorming and hunting around, we eventually found this genius configuration option that (notice the all important ‘.’ prefix) makes the cookie available to all subdomains on a domain. Finally we had truly shared sessions.

    ActionController::CgiRequest::DEFAULT_SESSION_OPTIONS.
        update( :session_domain => '.abcdefg.com')

4. Migrations / Models / Helpers / Deployment

The remaining issues are ones we are still facing and gradually solving. These tend to be less of a technical matter and more of an organisational one. We’re quickly establishing rules for how we order the migration files, share some models while keeping the security sensitive ones separate, bundling all of our helpers up into libraries and unifying deployment. We’re not quite there yet, but I’ll be sure to share our assumptions and solutions soon.

Russell Quinn » Ruby on Rails

Customising form controls in Rails

Multiple Rails applications