A quick Rails guide for designers May 28, 2012

I almost always work with great designers when building Ruby on Rails web applications. These designers are capable of doing amazing HTML and CSS and are already able to navigate a RoR directory structure or able to do so after a quick intro. I’m not focusing on this basic structure convention in this guide but instead I will be taking designers a step further and actually enable them to add a little bit of functionality to views i.e. enabling them to control some logic in *.erb.html files located in /app/views folder. Your designer need to be running your Rails app locally but that should be pretty common for agile teams.

To clarify, this guide is only useful for your designers working closely with you on a Ruby on Rails project. It’s supposed to be a pragmatic quick read telling your WHAT but not necessarily WHY. Here you still have to bug your developer.

I will go through these

• differencies between <% and <%= tags
• differencies between a "double quoted string" and a 'single quoted string'
• using cycle tag
• using dom_id tag
• using link_to tag and understanding rake routes

Ok, let’s go…

differencies between <% and <%= tags

Most developers tell designers to avoid touching anything between <% and %> tags. This is an obsolete mindset not fitting into a team with highly skilled members.

Code such as <% if @rides.any? %> does not output anything but code such as <%= @ride.title %> will.

differencies between a "double quoted string" and a 'single quoted string'

A code block like <%= "Picture of #{@car.name}" %> might output Picture of Porsche but a block like <%= 'Picture of #{@car.name}' %> will simply output Picture of #{@car.name}.

What’s to notice is that dynamic code in #{} is expanded within a "double quoted string" but not within a 'single quoted string'.

using cycle tag

Occasionally you are probably creating tables looking like

<table>
  <tbody>
  <tr class="dark">
    <td>Denmark</td>
  </tr>
  <tr class="light">
    <td>England</td>
  </tr>
  <tr class="dark">
    <td>Sweden</td>
  </tr>
  </tbody>
</table>

The example above cycles through rows setting a class of either dark or light. It is possible to hook this up using something like this

<table>
  <tbody>
  <% ["Denmark", "England", "Sweden"].each do |name| %>
  <tr class="<%= cycle('dark', 'light') %>">
    <td><%= name %></td>
  </tr>
  <% end %>
  </tbody>
</table>

You already know the <%= %> syntax which tells you to output something. Line 3 loops through all countries and on line 4 we are using the cycle method which will output dark on first row, light on second, dark on third, etc.

using dom_id tag

When building AJAX interfaces it is very common to need a unique ID for each element such as when printing a list of comments

<div id="comments">
  <div class="comment">
    First comment
  </div>
  <div class="comment">
    Second comment
  </div>
</div>

If your developer needs to add comments dynamically it will probably be hooked up using dom_id with code such as

<div id="comments">
  <% @comments.each do |comment| %>
  <div id="<%= dom_id(comment) %>" class="comment">
    <%= comment.content %>
  </div>
  <% end %>
</div>

The dom_id simply takes an iterated object and output a string useful as an element ID.

using link_to tag and understanding rake routes

Instead of creating standard HTML such as <a href="/users/sign_in">Log in</a> you are actually able to hook it up pretty easily by running rake routes in your Terminal. This will give you a list of available URLs such as

new_user_session     GET  /users/sign_in(.:format)  {:controller=>"sessions", :action=>"new"}
user_session         POST /users/sign_in(.:format)  {:controller=>"sessions", :action=>"create"}
destroy_user_session GET  /users/sign_out(.:format) {:controller=>"sessions", :action=>"destroy"}

Look at this and then take first part of a line matching your URL e.g. new_user_session and append it with _path then hook it up using <%= link_to 'Log in', new_user_session_path %>. It will generate the exact same output but if a developer afterwards thinks a URL for signing in should be /users/login he won’t have to go into each view to change it.

I am hoping this short guide will help your designers to bind just a little bit more logic into your views.