Robby on Rails: Tag ajax

Designers, Developers, and the x_ Factor

Robby Russell — Wed, 01 Aug 2007 00:39:00 -0500

Our team is lucky enough to be in a position where we have both designers AND developers working on the same code base in parallel.

Since Ruby on Rails adopts the Model-View-Control pattern for separating business logic from the presentation layer, we’re able to give our designers a lot of breathing room to to design the interface, whether it’s for interaction or aesthetic reasons. However, sometimes this breathing room has resulted in small bugs slipping into the application interface. In general, nothing disastrous, but each bug that slips into the queue, slows down the project and we want to avoid as much of that as possible.

I’d like to share a few issues that we’ve seen occur on various occasions, and then show you what we’ve done to avoid them happening again.

Scenario #1: The case of the changed div id, (victim: designer)

Designer adds a few HTML elements to the page, defines an id on a <div> tag and styles it with CSS.
A few days later, a developer needs to make some changes, tests it in their favorite browser and commits.
Later, the designer doesn’t understand why the styling is all messed up. “It was working fine.”
...minutes, hours… go by where the designer tries to track down the issue. “Oh! Someone renamed the id in this <div> tag. Sigh.”
Developer apologies, but explains that he needed to do it because he needed to make it work with his new RJS code.

Scenario #2: The case of the changed div id, (victim: developer)

Developer is implementing this cool new Ajax feature into the web application
- The code relies on there being one or many HTML elements in the DOM with specific id values defined.

Example: <div id="notification_message">

A few days later, a designer is making some changes to the layout and needs to restyle some of the view that this <div> tag is defined. Designer decides to change the id to a different value for any variety of reasons. (or perhaps they changed it to use a class instead of styling it by the id). Often times, we don’t know who set the id or class… and many times the developers aren’t savvy enough with HTML and designers end up cleaning things up a bit.
Later, code is checked in and designer didn’t notice that the Ajax was now breaking as they weren’t focusing on just the layout.
Day or two later, developer sees bug, “Feature X isn’t working, throwing JavaScript error…”
Developer is confused, “Hey, that was working! What happened?”
Developer tracks down the problem, discusses with designer, they figure out a solution. Problem solved.

I could outline a few other examples, but I really wanted to highlight these two types of situations, as our team has seen this happen on several occasions. Luckily, we’ve learned through these experiences and have taken some measures to try and avoid them in the future.

Moving forward (together)

Both of the examples above, were essentially the same problem, but resulted in problems for a different role in the design and development cycle. While, I’ve definitely been the victim of #2 several times myself, I know that I’ve also been the guilty of #1. So, what can we do as designers and developers to work with each other without causing these little problems from occurring? (remember: many little problems can add up to a lot of wasted time spent resolving them)

Several months ago, I had a meeting with Chris (User Interface Designer) and Graeme (Lead Architect/Developer) to discuss this very problem. At the time, we were implementing a lot of Ajax into an application and were occasionally running into Scenario #2. We discussed a few possible ways of communicating that, “yes, this div id should NOT be changed (without talking to a developer first)!”

Idea 1: Comment our “special” HTML elements

We discussed using ERb comments in our views to do something like the following.


  <% # no seriously, please don't change this id, it's needed for some Ajax stuff %>
  <div id="notification_message">
    ...

We all agreed that, while effective, it was going to clutter up our RHTML code more than any of us desired.

Team Response: Meh.

Idea 2: Reserve id’s for developers

Another idea that came up, was to ask that designers only use classes and ids wold be used by the developers when they needed it.


  <div id="developer_terriroty" class="designer_territory">
    ...

Chris pointed out that this wasn’t an ideal solution as there is a distinct case for when to use ids versus classes.. and he is very strict about adhering to the HTML/CSS standards.

Team Response: Not hot about it…

Idea 3: Naming convention for Ajax-dependent elements

The third idea that was discussed, was specifying a naming convention for any elements that were needed by our Ajax code. We played around on the whiteboard with some ideas and settled on the idea that we’d prefix our id’s with something easy to remember for both designers and developers.

We agreed on… x_ (x underscore), which would make an element id look something like this:


  <div id="x_notification_message">
    ...

x == ajax... get it?

While this adds the strain of typing two more characters to much of our RJS code, we don’t run into Scenario #2 very often anymore.


  render :update do |page|
    page[:x_notification_message] = 'Something exciting happened... and this is your notification!'
    page[:x_notification_message].visual_effect :highlight
  end

or in client-side JavaScript (where we also use this)...


  $('x_notification_message').do_something

I find that this helps our team keep a clear distinction between what can and shouldn’t be changed in the views by our designers. Sometimes they have a good reason to do so, but they know that if there is x_, then they should ask one of the developers on the team for assistance in renaming it without causing any problems in the application. It also allows our designers to add classes to these elements, or style the id that we’ve defined.

Team Response: Wow, was that all we needed to agree on? Hooray!

This leads me to some other problems that have/may come up, but I’ll discuss that in my next post on this topic, when I’ll show you how we can use RSpec to avoid these sorts of designer versus developer problems.

If you’re working in a similar environment, how are your designers and developers working, together, in perfect harmony?

Until next time, remember to hug your designer. ...and if you’re still having developer design your applications, consider hiring a designer. ;-)

UPDATE: changed examples after a few comments about using div_for as another solution. (see comments for details)

Speaking at Ruby on Rails Seminar in October

Robby Russell — Thu, 20 Jul 2006 17:29:00 -0500

It must be summer and I must be busy as I haven’t been posting much of anything on my blog over the past two months. Please forgive me! :-)

Just a quick mention that I’ve been invited to speak at the Ruby on Rails Seminar, to be held on Tuesday, October 3, colocated with the AJAXWorld Conference & Expo, October 2-4, at the Santa Clara Convention Center, Santa Clara, CA.

I’ll be presenting a new talk with an oh-so-familiar topic… Rails meets the Legacy-World. It’ll be nice to get to share the stage with some of my favorite Rails colleagues… such as Steven Baker, Joe O’Brien, and Michael Buffington.

For more information on the event, visit http://www.rubyonrailsseminar.com.

Fluxiom Unleashed!

Robby Russell — Thu, 20 Apr 2006 08:05:00 -0500

While in Vancouver BC, I had the privilege of meeting Thomas Fuchs, the guy behind script.aculo.us and mir.aculo.us. His company Wollzelle has just launched their new web service called, fluxiom. I’ve seen the videos and saw him demo some of it at Canada on Rails. The stuff that they’ve trained the browser to do with AJAX is unbelievable and it’s also built on Ruby on Rails! :-)

They are offering a free 30 day trial... so go check it out!

http://www.fluxiom.com/

When TSearch2 Met AJAX

Robby Russell — Sun, 21 Aug 2005 21:48:00 -0500

Last night, a local PDX.rb-ist, asked about full text searching in PostgreSQL. I pointed him to TSearch2, which is a nice little addon to handle full text searching with indexing, ranking, highlighting, etc. To my knowledge, it’s the closest to a google-like search that you can get with PostgreSQL. Some people in #postgresql (irc.freenode.net), said that you can build custom functions that will allow you to quote content, and do other fun stuff within your search string. We can discuss that another time.

After thinking it over, I thought, “why not put ajax on top of a full text search and see what it can do?”

The first question, where was I going to get a bunch of content that I could search through and have it be somewhat meaningful for the public, if I decide to put it up as a demo page. The RubyOnRails mailing list came to mind, so after seeing that I couldn’t download the full archive from the rails mailman page (at least not that I could tell), I decided that I would just import my Maildir for that mailing list.

This added another initial step. What would be a good way to import the 13,000~ emails that I had in the folder?

I knew that worst case, I could find a module on CPAN and build a perl script to import it… since I didn’t see anything in the standard ruby library. Then I found TMail. Someone said that they think ActionMailer uses TMail as well.

The resulting quick and dirty script became:

#!/usr/bin/env ruby

require 'tmail'
require 'rubygems'
require 'postgres'
require 'dbi'

conn = DBI.connect("DBI:Pg:database=rails_mailinglist;host=localhost;port=5403", "username", "password" )

MAILBOX = ".MailingLists.Ruby.RubyOnRails"

sql = "INSERT INTO archives (sender, recipient, subject, body) VALUES (?,?,?,?)"

@sth = conn.prepare(sql)

box = TMail::Maildir.new(MAILBOX)

box.each do |port|
        mail = TMail::Mail.new(port)
        p mail.subject
        @sth.execute(mail.from, mail.to, mail.subject, mail.body)
end

exit

Not rocket science. :-)

Okay, so I let that start running through the mailing list emails that I have, and opened up another tab in iTerm and typed our friend, rails archives followed by cd archives. The next step was to modify the config/database.yml file.

(you all know how to do that, right?)

Okay, you should still be with me…so far.

After I got my database settings in place, I ran ./script/generate scaffold Archive and watched it created my new filles to play with.

./script/server and I am looking at the first several emails that are in my RubyOnRails mailing list folder. I notice that the first one is the confirmation email from the day that I signed up on the mailing list. Mon, 24 Jan 2005 16:00:14 +0000 (GMT) . So, I delete that email and the ‘welcome to..’ one so that no one sees my mailman password/confirm info. ;-)

Installation

So, Rails has no problem with the data. So, I then head over to the Tsearch2 site and look for some installation information. I walked through this walkthrough

Database Structure

For this example, I kept it pretty simple for the database structure. I believe the create script was:


CREATE TABLE archives (
  id SERIAL PRIMARY KEY,
  sender VARCHAR(255),
  recipient VARCHAR(255),
  subject VARCHAR(255),
  body TEXT
);

The rest was basically following through with those steps and building the triggers and functions around the subject and body fields in the table.

To use the tsearch2 functionality, I used find_by_sql rather than using just find.


@archives = Archive.find_by_sql("SELECT id, headline(body,q) as headline, body, rank(idxfti,q) as rank, sender, subject  FROM archives, to_tsquery('#{@str}') AS q WHERE idxfti @@ q ORDER BY rank(idxfti,q) DESC LIMIT 100")

The @str variable is a value that I build based on the string(s) that the user is typing in the search field. Tsearch2 requires that you sepeare each string with a pipe (|). So, I put in a few checks on the string that was being passed to my method in my controller by AJAX. (I’ll let you take the time to figure out how to get AJAX in Rails working and watching a text field… it’s not hard to find info on google. ) :-)

The end result?

I will warn you that this does’t work in all browsers, some IE people said they had issues… and I spent enough time tinkering with it to just settle with this for now. :-)

I present… fulltext searching with PostgreSQL on Rails.

There are approx 13,000 emails in the system, so I put a limit on the number of responses that show up to 100.

My Thoughts

Well, it was an interesting concept. I’m not a big fan of livesearching, it doesn’t really seem to buy us much when working with this sort of data. I do find live auto-completion to be quite useful though. It’s not practical to have AJAX peg the database every second as I type for new content and it’s obvious that a database with that much content is not going to respond as snappy as you would hope. However, I decided to compare the speed to searching in Thunderbird and Evolution. From my sophesticated benchmarking suite (my imaginary stop watch)...

AJAX won!

okay, I should be fair and say, Tsearch2 won as it is doing all the heavy lifting.

Enjoy!